W3C home > Mailing lists > Public > public-qa-dev@w3.org > May 2006

(CSS) validator homepage cleanup, CSS modifications, added documentation

From: olivier Thereaux <ot@w3.org>
Date: Tue, 23 May 2006 12:05:39 +0900
Message-Id: <7CCF430E-1A6A-42A5-AFF7-B3337AB0467D@w3.org>
Cc: QA Dev <public-qa-dev@w3.org>, Peter Zhelezniakov <Peter.Zhelezniakov@Sun.COM>
To: Antonio Cavedoni <antonio@cavedoni.org>, Yves Lafon <ylafon@w3.org>

Hi Antonio, Yves, all

This is a follow up to my earlier messages about "tabtastic, etc":
http://www.w3.org/mid/7ce7cc424bcfe59872b9093d8d49b57e@w3.org
http://www.w3.org/mid/a0b0a5b3b9ee5a20d2f4655974c04f95@w3.org
and the result of some work done by Jean-Guilhem, Damien and myself,  
also based on ideas and work by Antonio.


** Home page

I have been following up on ideas discussed a little while ago with  
Antonio (and an image mockup Antonio had made) to see how we could  
make the main interface for the CSS validator cleaner, and therefore  
(hopefully) easier to use.

in http://qa-dev.w3.org/~ot/css-validator/validator.html.en you can  
see the latest version of that work. Worth noting:

- the three form fieldsets are "collapsed" into one, and a script- 
driven tabbed interface provides navigation between them. Browsers  
without javascript (enabled) see the three fieldsets, as currently  
available on the production service.

- the additional options are on the same page as the "basic"   
interface, only hidden and possibly triggered. This means that with  
this reorganization of the home page, there would be no need for the  
pages with the "specific" interfaces. IOW, what we have now at:
http://jigsaw.w3.org/css-validator/validator-text.html.en
would have to be redirected to
http://jigsaw.w3.org/css-validator/validator.html.en#validate-by-text

- the "menu" links are at the bottom, yet easily visible since the  
page is rather compact

Some of the remaining issues:
- for browsers with CSS capabilities but not javascript, the optional  
fields are hidden, and triggering their visibility is not possible. I  
want to change that, make the fields visible by default and trigger  
their visibility to off when a js-enabled browser sees the page

- there is a visual glitch with IE6/Win, which allocates some space  
for the fieldset legend if the element is in the document tree,  
regardless of the fact that the legend are styled with CSS as  
display:none. This causes the background color of the fieldset to  
"leak" outside of the box. I'd like to find a solution to that,  
preferably one that would not involve getting rid of the <legend>s.

- the "CSS validation service" at the top is actually an image, which  
allowed me to circle the blue text with a tiny white glow, which  
proves useful for small windows, when the text get above the "fuji"  
banner. However, this effect is only possible with png alpha  
transparency. Which means that for IE6, it's either very ugly (if  
serving a png) or rather ugly (if serving a gif alternate)


** Documentation

Damien, Jean-Gui and I have been working on refactoring the (awful)  
documentation for the CSS validator. New offerings include:

- a documentation index (similar to that of the markup validator)
http://qa-dev.w3.org/~ot/css-validator/documentation

- an "about" page, modeled as a general FAQ
http://qa-dev.w3.org/~ot/css-validator/about

- a user manual
http://qa-dev.w3.org/~ot/css-validator/manual.html.en

- a download, installation, usage guide
http://qa-dev.w3.org/~ot/css-validator/DOWNLOAD.html.en
(which would replace the existing RUN and DOWNLOAD documents)
Note that with this guide, installing the CSS validator on e.g tomcat  
is terribly simple, which is great progress!

All the documents above are using the "proposed new CSS" discussed  
above for the home page.


Things that remain to be done:

- get rid of BUGS, redirect to bugzilla

- redirect RUN(.*) to DOWNLOAD

- clean up/update style of the README (developer's readme), HOWTO  
(developers' doc on adding property, hopefully we can get rid of this  
completely some day) and Email pages.

- get all this new text translated!


  **  validation results pages

I have not touched that yet, but this will need some work. On the top  
of my head, I think we could:
- change the title for "valid CSS information". This is just a  
terrible term, for what is a compact view of the validated style  
source. It should also be styled specifically, perhaps in a way  
similar to the source in the markup validation service, for consistency.

- give some style to the errors and warnings. Perhaps try to get  
close to what the markup validation service does.


** Next steps

I have not yet committed all these changes to CVS, because although I  
have received some rather good feedback from a few users of the  
service, who found the work in progress "much better" than what we  
have at present, I'd like your ideas too. Constructive criticism,  
focusing if possible on usability, ease of finding some important  
elements and links, suggestions to improve/clean up the stylesheets,  
rather than hair splitting about aesthetical considerations would be  
welcome. A thorough proofreading of the new documentation would also  
be much welcome.

After a first round of feedback, unless there is an overwhelming  
feeling that the changes are not going in the right way, I will be  
committing the files to CVS, and I hope we can work together to  
polish remaining issues and finish tasks left out for the moment  
together, and send it for a round of public scrutiny.

Last, but not least, tricky issue: I made the visual changes to the  
CSS validator, mostly because it was the service which documentation  
I was working on, but these changes should also benefit the markup  
validator, feed validator, rdf validator. at least... The 4 services  
are rather similar, at least in their user input interface, but  
rather different in their reports. To which extent could we make them  
more consistent? And, supposing that they remain a little different,  
how could we make sure that their style/UI match, and how do we  
manage/sync the 4 stylesheet sets? For the latter question, I wonder  
if we could move the style sheets to a specific area in CVS, and have  
the 4 tools use a checkout of that, instead of having 4 style sheet  
sets managed in 4 different locations...


Thanks,
olivier
-- 
olivier Thereaux - W3C - http://www.w3.org/People/olivier/
W3C Open Source Software: http://www.w3.org/Status
Received on Tuesday, 23 May 2006 03:05:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:46 GMT