[CSSWG] Resolutions Boston F2F 2007-11-05: Priorities and Designer Feedback

I listed this section in
but didn't put in the content yet. Here 'tis:

Priorities and Designer Feedback

   Daniel Glazman brought up http://www.w3.org/TR/1998/NOTE-CSS-potential-19981210
   and how we haven't been aligning our work with designer needs, even with the
   feedback that we have already. This sparked a long conversation, which I don't
   think I can summarize, but I'll try to pull out some of the points made here.
   Note that these points aren't representing WG consensus, just some ideas that
   came up in the conversation: partly quotes, partly paraphrasing, partly

     - We have not done a good job of considering user feedback.

     - Some of the requests in the feedback were not pursuable for various reasons
       back when the feedback was given; others were simply not acted upon.

     - We have some feedback in
         http://www.w3.org/Style/Group/WD-CSS-future (internal, mostly the same as above)
       We should examine these lists and see
         a) if the issue is still relevant
         b) if we are ready to solve them

     - We've been dominated by browser makers and need more user input, but
       we are not set up in a way that makes it easy to collect this information.

     - CSS is driven forward both by pull from features specified by the CSSWG
       and by push features developed by implementors.
     - Some ideas fly; others do not; we need to piece together solutions from
       the best parts.
     - Where there is no champion for a spec, progress on that spec ceases.

     - Interoperability is important to web designers.
     - Good test suites drive interoperability. Wrong test suites drive
       interoperability on wrong behavior.

     - We should solicit and respond to user feedback.
     - We should use the CSS blog to collect feedback -- but we don't have that
       capability now -- [various technical suggestions on what to do]
     - We are happy for the CSS Eleven or any other group to gather feedback
       and process/organize it into something we can act on.

     - We should document personas, use cases for what we're trying to do.

     Someone diagrams our efforts into the following sections:
       * Readability (typography, fine layout)
       * Printing
       * UI / coarse layout
       * Internationalization
       * Foundation (e.g. box model)
       * Programmability (making desired results easy to declare)

   See also http://lawver.net/archive/2007/11/12/h17_web_standards_three_buckets_of_pain.php


Received on Wednesday, 14 November 2007 17:47:34 UTC