Re: A bug's life

Hello Jean-Guilhem, all,

Thanks a lot Jean-Gui for reviewing all of the bugs in the current  
validator.
Below are the notes I took while reviewing your review.

On Jul 19, 2007, at 09:31 , Jean-Guilhem Rouel wrote:

>
> * 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

When using upload, we would also have a media type. So the absence of  
media type would only be a proble for "direct input". There,  
heuristics to guess whether the content is CSS or HTML might be a tad  
tricky (think of the cases where people put html-style comments in  
CSS stylesheets...) but feasible.

[comment added to the bugzilla entry]

> 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
>

Fair question, although we do know that the main usage of CSS is to  
style HTML and SVG, and that could remain a  decent assumption. Do we  
still have a list of html elements?

[comment added to the bugzilla entry]


> 177 -> not sure we want to use POST as it seems to be against the  
> HTTP 1.1 spec

In theory I agree. In pragmatic terms, though, it is indeed true that  
most UAs have a hardcoded limit to the URIs they can GET, and that's  
a clear usability issue for our users. As much as GET is useful for  
debug purposes, I'd be OK with using POST for the direct input, as we  
already do for the markup validator.


> * 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
>

Could it be that it was fixed for <link> but not <style>?


> 759 -> probably means to perform a HEAD on each <link> and see if  
> the content-type is text/css
>

I was actually surprised to see that the HTML401 spec does NOT  
recomment using the attribute. In this context, I agree with you.


> 762 -> I don't understand the issue...
>

I added some comments to the bug. I think the problem is that, when  
validating an HTML page, CSS in style="" attributes does not appear  
to be checked.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=762

> 768 -> don't know what to do...
>

I added some comments to the bug entry.
[[ We moved the "level" of this warning to the lowest level, amongst  
other warnings of potential accessibility issues. I think this is the  
closest we can get to consensus. ]]

This also means that only thos who request "all warnings" will get  
the warning. This should make everyone happy (enough).

I have since closed the bug.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=768

> 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
>

This is a tricky edge case, dealing with broken server.
I'd be tempted to close WORKSFORME.


> 888 -> this one is also a bit strange to me, I don't know the X(HT) 
> ML specs enough to understand it
>

Not sure what the person meant.
To be tested:
* does an HTML document with only <style> element and no link get  
properly validated
* does the validator properly parses and fetches stylesheets linked  
with <?xml-stylesheet ?
If both are yes, then his issue should be moot.

[I added this comment to the bug report]


> 892 -> olivier, is it reasonable to add such a statement?
>

I closed the bug as WORKSFORME.
http://jigsaw.w3.org/css-validator/about.html#reference is enough, IMHO.
If people disagree they can reopen the bug. In the meantime, moving  
on...


> 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

Tough indeed.


> * 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)
>

+1


> 2347 -> not sure we want to do that. Olivier?

While indeed we give people the choice and tools to give access to  
checklink, does not mean we want all our services, especially the  
very heavily-loaded ones like the CSS validator, crawled, by this  
robot or others.

The W3C link checker will keep mentioning that the link hasn't been  
checked, but that is not an error.

I closed as WONTFIX.


> * 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?
>

Ditto 768. I haven't seen anyone complain since moving these warnings  
under the threshold showm by default.
People who ask for "all warnings" will get these, but they know what  
they want.
=> closed

> 2493 -> http://jigsaw.w3.org/css-validator/manual.html

closed


> 3300 -> does not look like a valid bug or improvement request. The  
> error message is pretty self-explanatory
>

I agree that there is no bug, so will close INVALID. However, I think  
there is roomto learn from it. Especially when the spec uses single  
quotes in its definition of the acceptable values, it's easy to be  
confused.
Assuming that everyone understands the specs as well as we do is the  
key to making an unusable product.
This is precisely why I would like to see error message explanations  
for the CSS validator, like we do for the CSS validator.


> 3626 -> might be fixed since we switched to tag soup, but needs to  
> do some tests before cloing. Yves may also help
>

I assigned this to me, will test.


> 3627 -> seems to have been fixed by the guy from Sun (is he still  
> working on the CSS Validator?)

Peter tends to be busy, but submits a patch now and then - his  
patches are good :)
The patch is on production service, so I closed the bug.


> 3628 -> maybe same bug as 3627. Does the fix to 3627 work for 3628?
>

Dunno, but it looks fixed. Needs more testing.


> 3629 -> idem
>

Yes.

Bugs 3627, 3628, 3629 should have test cases added to our test suite,  
if not done yet.



> 3633 -> seems to be fixed
>

Kind of. The error output is over-escaped, but indeed the parsing is  
correct.
Anyone knows what/who fixed it?


> 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)

What does the validator use for transcoding? iconv?


> * 4094 -> easy to fix
>

see also 2252 :)


> 4105 -> seems to work well. Olivier, do you have more info? Yves,  
> is it related to tag soup?

Actually, it does not work. The person just changed the page she used  
as test case.
I changed it to use a relevant test case.


> 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?
>

No idea. Without a test case and a clear bug report, hard to tell.


> 4560 -> not directly related to the validator, but rather to CVS.  
> Olivier, Yves, do you know what's wrong?
>

I assigned this to me. Will look.


> * 4828 -> I've conscientiously tried to avoid messing with BOM  
> during my internships, but I'm sure you two can fix it!
>

That would be *really* good. Windows text editors tend to add BOMs  
quite consistently these days, it seems.

Thanks again!
-- 
olivier

Received on Thursday, 19 July 2007 09:33:54 UTC