[CSSWG] Minutes and Resolutions Telecon 2012-05-23


   - RESOLVED: John's proposal to resolve the issue is accepted, exact wording
               to be settled on list
   - RESOLVED: Alignment properties to be named
                 align-self / align-content / align-items
                 justify-self / justify-content / justify-items
   - RESOLVED: use space-between/space-around instead of justify/distribute
   - RESOLVED: rename flex-order to order

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

   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   Phil Cupp
   David Baron
   Ryan Betts
   Bert Bos
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   John Jansen
   Brad Kemper
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Florian Rivoal

<RRSAgent> logging to http://www.w3.org/2012/05/23-css-irc
Scribe: sylvaing
glazou: other agenda items?

font-family syntax and reserved keywords

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0630.html
   <jdaggett> font-family: [[<family-name> | <generic-family>]
                            [, <family-name>| <generic-family>]* ] | inherit
   <jdaggett> <family-name>    == [ <string> | ident+ ]
   <jdaggett> <generic-family> == [ sans-serif | serif | cursive | fantasy | monospace ]
   jdaggett: there is a slight ambiguity in the current grammar for
             font-family names
   jdaggett: in the current grammar reserved keywords can be matched either
             as keywords or a sequence of identifiers
   <jdaggett> http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
   jdaggett: in the paragraph linked above, keywords are required to be
              quoted to match the family name type
   jdaggett: so if you have an unquoted font name that includes inherit or
             initial it would have to be dropped
   jdaggett: there is some confusion across browsers. foo inherit can be
             valid while inherit foo might not be (or vice-versa)
   jdaggett: I propose we tweak the grammar and change the prose
   jdaggett: we should allow names like 'inherit foo' but inherit, foo
             would be invalid
   florian: I haven't looked at your grammar change but I'm comfortable
            allowing names such as 'inherit foo'
   tabatkins: I'm ok with that as well
   jdaggett: anyone else has objections?

   jdaggett: one change involves fixing the syntax
   jdaggett: second change is a rewording
   jdaggett: both for the CSS2.1 errata
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0630.html
   (both changes described in the post linked above)
   some discussion of wording
   <fantasai> s/are not allowed to/do not/
   <fantasai> otherwise, it's ok
   <bradk> reserved keyword if separated by comma, not if separated with
           space. Unless quoted.
   <Bert> (I proposed a note as an alternative to jdaggett's text, maybe
          that addresses Anton's concern?)
   <glazou> Bert:  please copy here ?
   <Bert> (My proposed note: "Note that 'font-family: Times, inherit' is
           therefore an invalid declaration, because 'inherit' in that
           position can neither be a valid keyword nor a valid font family
   jdaggett: this is not the best language. I'm only trying to make the
             most important change i.e. identify initial, inherit and
             default as not being magic family names
   dbaron: I just realized we want unquoted default inherit and initial
           to not match <family-name>
   dbaron: but I'm not sure the proposed language says that
   glazou: are folks ok with the change, modulo final language?
   RESOLVED: John's proposal to resolve the issue is accepted, exact wording
             to be settled on list
   ACTION jdaggett to finalize errata language
   <trackbot> Created ACTION-474

   <jdaggett> proposed wording for CSS 2.1 errata related to unquoted font family names:
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0852.html


   <fantasai> http://wiki.csswg.org/topics
   <glazou> http://wiki.csswg.org/topics?datasrt=&dataflt[]=spec%3Dcss3-flexbox
   tabatkins: we must resolve naming issues first so as to freeze the API

   <fantasai> http://wiki.csswg.org/topics/alignment-names
   tabatkins: first renaming alignment properties to generic names
   tabatkins: this derives from fantasai's css3-align proposal
   tabatkins: I'm ok with that
   fantasai: we already have a resolution on this, just need to settle on
             exact the names
   tabatkins: let the bikeshedding begin
   fantasai: do we prefer justify-items or justify-default?
   fantasai: a lot of people thought default was really vague so let's drop it
   szilles: what does items mean?
   <dbaron> I actually like default-*
   tabatkins: it is the default alignment for flex items
   szilles: so why is default a bad choice?
   tabatkins: it's not clear what is being defaulted
   * sylvaing thinks justify-all-the-things would be fine
   pcupp: in grid layout we operate on items just like flexbox does on
          flexbox items
   pcupp: I don't see the use case for having the item-alignment property,
          why not style the elements directly
   Tab: anonymous items, and it's just easier
   pcupp: Anonymous content seems more of an error case than something
   <dbaron> Was there a reason "child" wasn't considered as an alternative
            to "item" or "default"?
   <fantasai> dbaron, grid items it's not the child always
   glazou: any objection?
   RESOLVED: eliminate default as a naming option

   More discussion of various alignment choices.
   Straw poll...

     Set 1: Box/Content/Default
       A |     box-justify      box-align
       B | content-justify  content-align
       C | default-justify  default-align

     Set 2: Self/Content/Item
       A |    self-justify     self-align
       B | content-justify  content-align
       C |    item-justify     item-align

     Set 3: Outside/Inside/Items
       A | justify-outside  align-outside
       B | justify-inside   align-inside
       C | justify-items    align-items

     Set 4: Self/Content/Items Inversion
       A | justify-self     align-self
       B | justify-content  align-content
       C | justify-items    align-items

     Set 5: Self/Content/Items Inline/Stack
       A | align-self-inline     align-self-stack
       B | align-content-inline  align-content-stack
       C | align-items-inline    align-items-stack

   plinss: abstain
   glenn: 2
   glazou: abstain
   sylvaing: abstain
   antonp: 2,4
   jdaggett: abstain
   florian: 5
   rossen: 4
   rbetts: abstain
   johnjansen: 4
   arronei: 4
   bradk: 5
   tabatkins: 4,2
   smfr: 4 (don't like term 'stack')
   dbaron: my preference order is 2 [big gap here] 4 3 5
   szilles: 2 or 4. do not like 5
   bert: abstain
   <bradk> I don't like "justify" to mean "align x"
   fantasai: my favorite is 4. I'm OK with anything that is not 1
   hober: abstain
   RESOLVED: option 4

   pcupp: and the intent is to apply those names to grid as well
   tabatkins: yes
   fantasai: that was our resolution as the f2f

   <TabAtkins_> http://wiki.csswg.org/topics/justification-keywords
   tabatkins: for flex-pack properties there are two values that mean
              'spread the items out'
   tabatkins: in one case the items at either end are flush, in the
              other they're evenly distributed in the container
   tabatkins: justify for flushing, distribute for even spacing
   glazou: why don't we use the names you have there?
   glazou: edges-flush and equal-margins
   glazou: that's readable
   <sylvaing> +1 to glazou
   <rbetts> +1 to glazou
   fantasai: my concern is they make no sense when you don't already
             have the context "we're spacing things out"
   antonp: is there any reason why equal spacing is not part of flexbox
   fantasai: no one asked for it
   szilles: distribute-items/distribute-space?
   szilles: based on ruby align
   glazou: no-margins?
   <fantasai> justify-content: no-margins ???? Does not make sense.
   szilles: distribute-space maps to equal-margins
   * bradk thinks that 'justify' should be a value that means what it does
           in 'text-align'. Confusing to have it as alignment property name.
   tabatkins: my objection is that this really aligns margin boxes i.e. it
              distributes space between the margins
   * antonp likes szilles' way of looking at it
   <Rossen> justify-content: between | spread
   florian: if we can't agree on anything better than what's there, let's keep it
   rossen: +1
   dbaron: I think it's reasonable to give long names to those that add
           space at the edges since it's something we haven't had before
   tabatkins: it's a common usage pattern done with margins so far
   <fantasai> distribute-between | distribute-around
   <fantasai> ?
   glazou: this is difficult to straw-poll because we have discussed more
           proposals than what's on the wiki
   szilles: can we straw poll between 0 or something new?
   fantasai: how about distribute-between/distribute-around?
   <fantasai> space-between | space-around
   <Rossen> Like!
   dbaron: I'm confused as to whether you're trying to assign 2 or 3 names
   <rbetts> makes sense to me
   tabatkins: only two, we don't include the full space on each side scenario
   <SteveZ> +1 for space-between and space-around
   <fantasai> space-between | space-around | space-evenly
   glazou: straw poll between option 0 and space-around/space-between
   plinss: abstain
   glazou: 0
   sylvaing: 0
   antonp: 1
   jdaggett: abstain
   glenn: 0
   florian: abstain
   arronei: abstain
   fantasai: 1
   rossen: 0 then 1
   johnjansen: 0
   tabatkins: 1
   dbaron: abstain (though I might prefer splitting the difference, justify/space-?)
   bradk: 0
   szilles: 1
   bert: 1
   rbetts: 1
   hober: abstain
   RESOLVED: use space-between/space-around instead of justify/distribute

   <fantasai> http://wiki.csswg.org/topics/css3-flexbox-rename-flex-order
   tabatkins: next, renaming the flex-order property
   tabatkins: grid layout's auto placement is similar to flexbox's algorithm
              so we think there should be a common property: display-order
   fantasai: also, this property has nothing to do with flexing
   dbaron: this may be a bit confusing given the display property and
   dbaron: box-order?
   szilles: this reorder the items so item-order?
   bradk: just order!
   dbaron: item-order bad since we just made "item" something that applies
           to children rather than self
   szilles: I'm concerned about box-order if this property is to apply to
            region flows
   rossen: when you have multiple boxes for elements, do all the boxes
           have the same order
   fantasai: it works like z-index -- boxes with the same index are subsorted
             by document order
   <rbetts> +1 to just "order" as proposal D
   pcupp: what other ordering is affected? if you re-order input element
          does the tab order move around?
   tabatkins: at the moment no, tab order comes from document order
   straw poll
     A = flex-order
     B = box-order
     C = display-order
     D = order
   plinss: D, then B
   glazou: D, then B
   sylvaing: abstain
   antonp: not A
   jdaggett: abstain
   glenn: abstain
   florian: B or D, not A
   fantasai: not A
   johnjansen: abstain
   rossen: B
   arronei: abstain
   dbaron: D, then B
   tabatkins: D, C, B
   bradk: D then B
   szilles: D, C, B
   bert: abstain
   rbetts: D
   hober: abstain
   <Bert> (Steven Pemberton once proposed a 'something-order' property to
           reorder children, independent of the display model, like a
           generic transformation.)
   RESOLVED: rename flex-order to order
   <antonp> D both pleases and scares me

   TabAtkins: Last one for next week:
   <TabAtkins> http://wiki.csswg.org/topics/start-end-before-after-align

Meeting closed.

Received on Thursday, 24 May 2012 04:42:36 UTC