W3C home > Mailing lists > Public > www-validator-css@w3.org > July 2007

A bug's life

From: Jean-Guilhem Rouel <jean-gui@w3.org>
Date: Wed, 18 Jul 2007 20:31:09 -0400
Message-ID: <469EB0CD.508@w3.org>
To: www-validator-css@w3.org
Hi all,

I've reviewed all the open bugs in Bugzilla to help two interns 
currently working on the CSS Validator. It was originally intended to 
them, but we thought the community may also benefit from it. Feedback 
and comments are very welcome.

Jean-Guilhem Rouel                    http://www.w3.org/People/Jean-Gui
W3C Webmaster   MIT/CSAIL             http://www.w3.org/
Voice: +1.617.258.8143                Fax: +1.617.258.5999


* 152 -> should be easy to add. The hard part is to determine if we html or css was submitted. In Unicorn, we do that using a dropdown list of mimetypes, but here it should be possible to guess the type from the content
154 -> the problem I see is that the css validator is not tied to HTML. How do we know if img is the html's img tag or something else? We could issue warnings only if we know that a CSS is linked from an HTML document
176 -> easy to fix
177 -> not sure we want to use POST as it seems to be against the HTTP 1.1 spec
* 697 -> was supposed to be fixed, so there may be something in the code. Should checkout the revision corresponding to 26 August 2005, see if it's fixed and why the fix doesn't work anymore
759 -> probably means to perform a HEAD on each <link> and see if the content-type is text/css
762 -> I don't understand the issue...
768 -> don't know what to do...
801 -> not sure we have something to do, maybe catch the exception to print a more beautiful message
814 -> test case is gone :-/, would need to create a new one and see if it's possible to improve the message in this case
831 -> the css validator works well with password protected areas of www.w3.org. The behaviour might be different because there are several WWW-Authenticate headers.
888 -> this one is also a bit strange to me, I don't know the X(HT)ML specs enough to understand it
892 -> olivier, is it reasonable to add such a statement?
1073 -> will probably be quite hard to fix as we use a single parser for all profiles. If the behaviour was bad with all profiles, it would be "easy" (as long as we consider modifying the CSS parser an easy task) to fix the parser, but as it's only for CSS3, it's a lot harder
* 2252 -> partially fixed, but the results are still using the content-language value. Easy to fix, adding a query string parameter that would override the content-language (see bug 4094)
2344 -> see http://jigsaw.w3.org/css-validator/validator?text=a+%7B%0D%0Abackground%3A+url%28%27brol%27%29%3B%0D%0Acolor%3A+%23ddd%3B%0D%0A%7Dwarning=2, but I am not sure this is a bug. Bert's expertise is welcome, but not providing background-color may lead to unexpected behaviour on UAs with no image support for example
2347 -> not sure we want to do that. Olivier?
2403 -> would need to find some doc on how Java handles UTF-16
* 2421 -> long-standing discussion, people simply don't understand that warnings are here to point out possible issues, and don't understand either the purpose of this very warning. The best thing to do is to reword the warning I think, saying that no 'real' color has been specified (s/real/whatever would make people understand the warning/). Olivier, Bert, any idea?
2493 -> http://jigsaw.w3.org/css-validator/manual.html, but people usually don't read docs... I think we can close this bug
* 2801 -> already discussed about it in an email:
  > We tried to fix this bug by using URLEncoder class but it wasn't working because this class encodes spaces to '+' instead of '%20'; more information about this issue can be found here <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4616184>.
  > The solution might be to simply replace all the spaces in the URI by '%20' in the doGetMethod of the org.w3c.css.servlet.CSSValidator:
  > 332:        uri = HTTPURL.getURL (uri).toString(); // needed to be sure
  > 333:        // that it is a valid
  > 334:        // url       335:+       uri = uri.replaceAll(" ", "%20");
  > 336:        DocumentParser URLparser = new DocumentParser(ac, uri);
  > 337:
  > 338:        handleRequest(ac, res, uri, URLparser.getStyleSheet(), output,
  > 339:                  warningLevel, errorReport);
  > Indeed, this solution may seem to be rather apparent, but it works fine and is more reliable than other approaches that we tried instead.
  Reading http://www.kirit.com/W3C%27s%20CSS%20validation%20service, the problem seems to be in the redirection /css-validator/check/referer -> /css-validator/validator?uri=... this redirection doesn't seem to encode % to %25. The change you've made solves the issue for spaces, but probably not for other special characters.
  Unfortunately, I don't know how this redirection is performed. Yves probably knows how to fix it, Olivier may too. 
2920 -> already mostly fixed, but @charset/**/ "utf-8"; should probably be an error. Bert, is that right?
3115 -> might be related to bug 2801. Needs a testcase before trying to fix it
3127 -> test case: http://jigsaw.w3.org/css-validator/validator?text=%5Cb+%7B%0D%0Aborder%3A+none%3B%0D%0A%7D&usermedium=all&warning=1&profile=css21&usermedium=all \b becomes the symbol for male gender. Probably related to how Java handles special UTF-8 characters
* 3140 -> http://jigsaw.w3.org/css-validator/validator?text=%40import+%27foo%27%3B&usermedium=all&warning=1&profile=css21&usermedium=all. Seems to be an interesting bug to fix. Maybe a warning would be better than an error if the URL is not reachable
* 3191 -> probably easy to fix. There must be a Java function to that automatically
3300 -> does not look like a valid bug or improvement request. The error message is pretty self-explanatory
3313 -> Bert, could you provide us some input on how the CSS validator should handle comments, maybe test cases and expected results?
* 3424 -> should hopefully (we never know with the CSS Validator ;)) be easy to fix
3626 -> might be fixed since we switched to tag soup, but needs to do some tests before cloing. Yves may also help
3627 -> seems to have been fixed by the guy from Sun (is he still working on the CSS Validator?)
3628 -> maybe same bug as 3627. Does the fix to 3627 work for 3628?
3629 -> idem
3630 -> seems to be fixed, even if the message is probably not very accurate. Bert?
3631 -> Bert?
3632 -> Bert?
3633 -> seems to be fixed
3634 -> Bert?
* 3691 -> bug in the Unicorn template
3775 -> needs a test case
3804 -> way to vague
4044 -> would be nice to test the validator against all sorts of encoding, and see how to handle most of them (if not already the case)
* 4090 -> that's an important one to fix I think
* 4092 -> test case + fix should not be very difficult
* 4094 -> easy to fix
4105 -> seems to work well. Olivier, do you have more info? Yves, is it related to tag soup?
4267 -> test case is gone, but I think the guy was using a length without a unit. So I think it's not a valid bug. Olivier? Bert?
* 4284 -> test case + fix in the templates or where the error is generated
* 4335 -> probably a tough one. Needs to work on the parser.
* 4346 -> can probably be fixed in 10 seconds
* 4362 -> need to add a new CSS3 property I think
* 4397 -> first needs to narrow the test case
* 4455 -> related to 2801 and/or 3115
* 4469 -> I tend to think that solving 4397 will also fix this one
4560 -> not directly related to the validator, but rather to CVS. Olivier, Yves, do you know what's wrong?
4576 -> no idea. You can have a look at it if you like SSL ;)
4631 -> Yves, oh WSDL Grand Mastah, can you check that the WSDL file is correct?
* 4828 -> I've conscientiously tried to avoid messing with BOM during my internships, but I'm sure you two can fix it!
Received on Thursday, 19 July 2007 00:31:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:43 UTC