[CSSWG] Minutes and Resolutions 2008-11-04

Summary:

   - Discussed definition of :enabled and :disabled, general agreement
     that it should be defined by the markup language but needs proposed
     wording.

   - Briefly discussed ::selection, but did not get into details
       http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html

   - RESOLVED: Proposal to remove IDEOGRAPHIC SPACE U+3000 from list of
     characters affected by word-spacing accepted.

   - Briefly discussed border-parts

   - Reminded Bert that we had agreed not to formally publish CSS2.1
     again until we're ready to go to Last Call in preparation for PR.

   - David Baron requested a wiki page that tracks what CSS2.1 tests
     need to be reviewed.

   - Dates for Tokyo F2F set for March 4-6.

====== Full minutes below ======

Attendees:

   David Baron
   Bert Bos
   Giorgi Chavchanidze
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Melinda Grant
   Peter Linss
   Hakon Wium Lie
   Saloni Mira Rai
   Jason Cranford Teague
   Jeff Willson

ScribeNick: sylvaing
agenda: +f2f dates

:enabled/:disabled
------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0295.html
   fantasai: spec does not do a good job defined :enabled and :disabled
   fantasai: need to change spec to make definition more vague/less
             dependent on user interaction
   <sylvaing> if we make it more vague, how do we converge on interop ?
   <fantasai> "— which the user can select or activate in some fashion
              (e.g. clicking on a button with a mouse)"
   <fantasai> I would suggest removing that
   glazou: not sure this solves the issue
   <dbaron> How about something more like "represents an element whose
            element type can be enabled by the user but cannot currently
            be activated by the user due to the semantics of the markup"?
   <fantasai> s/whose element type//
   dbaron: definition of enabled/disabled should not depend on CSS but
           semantics of the markup and object model
   <dbaron> not sure if "element type" is the right thing, but it is precise
   fantasai: we already have implementations that match type=hidden.
   <glazou> what happens for :enabled { display: none  } ?
   fantasai: html5 should define enabled/disabled
   fantasai: I personally think type=hidden should be able to accept
             :enabled/:disabled because that distinction exists
   fantasai: but that should be left up to HTML5, we should not define
             that here
   plinss: there was discussion to use CSS to determine whether something
           was editable i.e. its state
   dbaron: IIRC we decided that was a bad idea
   <Hixie> http://lists.w3.org/Archives/Public/www-style/2008Oct/0161.html
           is relevant here
   <Hixie> I prefer the first mechanism proposed
   ACTION fantasai: write rewording proposal for section CSS3 Selectors 6.6.4

::selection
-----------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
   dbaron: two issues 1) 3 proposals for ::selection 2) have not looked at
           existing impls and tests
   fantasai: unclear what Hixie's test assumes/expects
   glazou: discussion postponed to next week
   fantasai: When I looked at Hixie's tests, it looked like he set properties
             on everything, so it was not possible to see how values
             inherited/cascaded through the tree

Ideographic Space
-----------------

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-84
   no objection
   <glazou> change accepted
   <fantasai> RESOLVED: proposal accepted for issue 84

border-parts
------------

   hakon wonders whether repeat() should be kept in GCPM border-part
   melinda: agree it will be hard to preserve
   melinda: combinations can get very complex
   melinda: should we ask designers ?
   melinda: agree that border parts are generally useful
   discussion of what designers want
   jason: Control over spacing of dashes is a standard tool designers use
   fantasai: feature set for 3 is good and should get locked down for
             impl.; new proposal for dotted/dashed lines can go in
             borders & backgrounds 4

CSS2.1 Publication
------------------

   glazou: bert sent email today about CSS21 publication plan
   bert: SVG Tiny 1.2 depends on CSS2 since they need to depend on a REC
   bert: people cannot use CSS21 for their specs
   glazou: yes we do need to deliver this spec
   bert: we give the appearance to move backwards; we could avoid
         publishing anything until we have a PR
   fantasai: we said we'd do that in Cambridge
   fantasai: we can't go to PR without the test suite
   fantasai: and implementations that pass
   bert: should we give up on implementations ?
   fantasai: conflicts with the process document
   melinda: should we see where we are wrt test coverage and estimate
            time left
   plinss: we have not spent enough time on the test suite yet to decide
           today whether we should change the exit criteria to fasttrack REC
   bert: we seem to never get out of issues
   fantasai: we'll never be out of them; but once in REC we address them
             in errata
   bert: we should not wait for implementations to complete the spec
   plinss: we're waiting for the test suite, without which we don't know
           whether we have implementations
   bert: do we have estimates for how long it will take to complete the
         test suite and have test reports ?
   melinda mentions msft's coming test suite
   fantasai: once we have their test suite, reviewing them is the next item
   dbaron: are we designing a system to allow us to review tests or are we
           going to do something simpler
   fantasai: right now, simple system. wiki and mailing list
   dbaron: is there a wiki linking to tests needing review
   dbaron: in one place
   melinda: agree.
   dbaron: we should not gate progress on building a complex review system
   dbaron: I just want a list of what needs to be done.
   dbaron: otherwise it is hard to get involved and help
   <fantasai> http://wiki.csswg.org/test/css2.1/pending-review
   fantasai: record of which tests have been reviewed is not centralized
   glazou: should we move tests that need work, that have been reviewed,
           pending review etc be in different places in the repository ?
   fantasai: will look for a solution that does not involve moving things
             around all the time since moving files can lose versioning
             history if you don't do it right
   plinss: individual contributors should not do this, only reviewers
   glazou: expose a web frontend to do this so the backend does it right
           in subversion

F2F Planning
------------

   glazou: moving on to Tokyo f2f meeting
   plinss: can we lock dates within the first two weeks of march
   fantasai: is february a possibility ?
   arguing dates around sxsw
   glazou: we stick to the first week of March; 4, 5 and 6

Received on Wednesday, 19 November 2008 00:41:32 UTC