[CSSWG] Minutes Seattle F2F Mon 2014-01-27 PM I: Propdef Tables, Grid Layout, Issue Tracking

Propdef Tables
--------------

   Discussed the duplication of data (specifically, the form of computed
   values, which appears both in the Computed Value and Animatable lines)
   in propdef tables and what to do about it.

Grid Layout
-----------

   Deferring proposal for a joiner pattern in repeat() for now.

   Removing grid-auto-position property and grid-auto-flow: none value.
   Adding new 'stack' value (stacks items into first empty grid slot)
   instead. (Initial value is 'row'; Win8 apps might need 'stack'
   specified in the UA style sheet.)

   Grid Layout is considered design complete at this stage, and anyone
   planning to send feedback review it at the high level. Next phase
   will be working out exact details and wording of layout algorithms,
   etc.

Issue Tracking
--------------

   It was agreed that we have too many issue-tracking systems atm.
   However since they all suck (in different ways), there was no
   consensus on moving to a single tracker.

   RESOLVED: Be more vigilant about specs actually declaring their issue
             tracking style.

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

Propdef Tables
--------------

   Scribe: TabAtkins
   fantasai: [points out that computed value and animatable lines duplicate
             information in the propdef table]
   fantasai: Both say what the data model is for a property.
   fantasai: If the computed-value line was as rigorous and consistently
             defined as how we're structuring the animatable lines, we
             could just replace "animatable" with "yes" or "no" or "yes,
             except FOO".
   fantasai: I'd prefer not to say things twice, particular if they're
             slightly different wording.

   dbaron: "computed value" line is saying what space your value is in,
           and how to get it there.
   dbaron: While "animatable" is saying what parts of the space are
           animateable, and how.
   astearns: There are some cases where a value takes multiple kinds of
             values, and computed-value line says "compute it this way,
             or compute it that way", and animatable.
   dbaron: Animatable draws a distinction between a repeatable list and
           a simple list, for example, which computed value doesn't.
   dbaron: I'd like to see a proposal first, and I'd be skeptical before
           seeing that.

   ChrisL: Animatable line seems to mostly be patching in failures of
           the computed value line, with a bit more detail.
   ChrisL: I'd also like seeing worked-out examples for lots more properties.
           But I'm confident it would work.
   dbaron: There are many places in the spec which we could replace with
           "it's obvious", but it's not obvious to everyone, and that's
           why we say it.
   fantasai: Well, if a prop takes a length, it'll animate as a length,
             not a percentage or an angle.
   dbaron: But a computed value of "length or percentage or calc" is
           three possible terms, but in animation it's one thing.
   tantek: So what will y'all do?
   fantasai: I think go through a few specs and do all the conversions,
             making a concrete proposal from the experience.

Grid layout
-----------

   fantasai: Still have a few topics to discuss.
   fantasai: First is Issue 2.
   TabAtkins: This is about a "join argument" for the repeat function,
              to put something between the repetitions.
   fantasai: [draws example]
   fantasai: So add it now, or defer it?
   RESOLVED: Defer join argument of repeat() until later.
   <florian> scheme does (string-join strings separator)
   <florian> Haskell is the other way around though
   <florian> there is no consistent order to follow, we can do whatever
             we want.

   fantasai: Issue 3, default value for grid-auto-flow
   TabAtkins: Old behavior (implemented by MS) put items into cell 1,1
              by default, overlapping all grid items by default.
   fantasai: So, suggestions to resolve it:
   http://lists.w3.org/Archives/Public/www-archive/2013Aug/0024.html
   fantasai: 1) Don't do anything.  I don't think we'll be doing that.
   fantasai: 2) Put things in the first empty slot, with a "stack" value
                (or "deck").
   fantasai: 3) Add a way to specify where they stack.
   fantasai: 4) Just let MS define their own special value in the UA
                stylesheet, -ms-none or whatever, which has the "stack
                in 1-1" behavior.
   Rossen: I don't think this is much-used, and thus not really a compat
           issue either way.
   fantasai: I'd prefer, then, to not add grid-auto-position, as it's not
             that useful. At least not now.
   fantasai: So my suggestion is "grid-auto-flow: [row | column] || deck;"
   szilles: Don't like the name "deck". Why not "stack" or "pile"?
   TabAtkins: "stack" is already used in XAML for a different thing, so
              Rossen preferred not using it.
   multiple: don't really like "pile" ^_^
   [naming discussion]
   [quick straw poll for naming prefs: stack 13, pile 0, deck 3, layer 1]

   fantasai: So, we think the spec is design-complete.  Tab and I want
             to do an algorithm review, but that's it.
   rossen: need to decide on collapsing, fragmentation...
   fantasai: We have an open issue on collapsing, which we need to figure
             out and still have no ideas yet.
   Rossen: I have a proposal for general collapsibility. I'll post to
           www-style.
   fantasai: So if you want to review for general implementability, please
             do it now.  This is a call for general design review.

Issue Tracking
--------------

   SimonSapin: As I explained on the list, I think we have too many ways
               to track issues.
   SimonSapin: It took a year for me to learn that we have some bugs in
               W3C Bugzilla.
   SimonSapin: We also have tracker, in-spec, in-mailing-list, etc.
   SimonSapin: I'm sure there are some issues we knew about at some point,
               but forgot about.
   <glazou> think http://xkcd.com/927/ and apply s/Standards/Issue Trackers
   dbaron: Also, sometimes we have bugzilla and/or tracker components for
           specs where the spec's editors aren't using bz/tracker for
           that spec.
   dbaron: So things get dumped in there and lost.
   dbaron: I was trying to reduce the list of open issues for Transitions,
           which is in bugzilla.
   dbaron: Roughly half of the open issues need to be moved to other specs.
   dbaron: But I don't know how to do that.
   dbaron: The process is "ask the editor".
   astearns: Or "email the list saying it needs to be moved".
   dbaron: In many cases the issue in bz is a one-link link to a www-style
           list.
   dbaron: Another problem, some editors *have* gone to the effort of
           moving www-style issues to bugzilla, but I don't know at
           what date that effort stopped.

   ChrisL: Tracker is nice there, because it recognizes "Issue-XXX" in
           the titles.
   tantek: Isn't there already an agreement to track the issue-reporting
           place in the spec?
   TabAtkins: Not really.  We agreed, yeah, but we didn't follow it.
   plh: Because we use too many systems, it's too easy to get confused
        and use the wrong system.
   tantek: I think it's on the editor to deal with that.
   TabAtkins: But it doesn't work well today. I agree that having less
              issue-tracking systems are fine.
   tantek: Is this primarily a problem with multi-editor specs?
   TabAtkins: Nah, happens plenty with single-editor.
   dbaron: But it's often worse if editors transition over time.

   fantasai: A problem with Tracker is that only editors can update it.
   fantasai: I'm okay to drop Tracker.
   fantasai: What I don't want to transition out of is using text files
             for LC comments.
   fantasai: hard to get DoC with any of the other systems
   tantek: And I prefer using wiki...
   dbaron: I also find using bugzilla fairly painful.
   fantasai: Mailing list is great for collecting issues. It's not good
             for seeing if it's still open.
   astearns: If you see a mailing-list item, how do you get to the
             corresponding issue?
   fantasai: It would be more solveable if when I replied to the ML issue
             it actually showed up in the archive as a reply
   dbaron: If they cross month boundaries they don't show as replies...
   [missed something about threads and issues]

   dbaron: So, any conclusions?
   fantasai: Does anyone actually want to use Tracker?
   florian and fantasai use tracker, but doesn't mind not using it if
           that helps this situation
   ChrisL: Tracker has nice IRC / ML integration
   florian: for integration and simplicity, I kindof like tracker
   smfr: Tracker doesn't send you update emails.
   dbaron: I think I heard that the solution to the Transitions things
           is to just send email about them and closing them.

   SimonSapin: So here's a suggestion.  We tell people to open bugs on
               Bugzilla (or some system that actually tracks things),
               and have that spam the mailing list.

   RESOLVED: Be more vigilant about specs actually declaring their issue
             tracking style.
   <astearns> not to pick on you, TabAtkins, but you could add an issues
              link to the custom properties draft before you publish CR

Received on Thursday, 30 January 2014 13:42:04 UTC