W3C home > Mailing lists > Public > www-style@w3.org > June 2012

[CSSWG] Minutes and Resolutions Telecon 2012-06-06

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 06 Jun 2012 13:28:43 -0700
Message-ID: <4FCFBD7B.3080907@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Transitions, Transforms, and Animations may be released unprefixed.
   - RESOLVED: Write document explaining prefixing policy as WG Note.
   - RESOLVED: Publish FPWD of Box Align, with corrections + note about how
               Block and Table interaction is still uncertain.
   - Tab and Florian summarized the state of the variables syntax debate
   - RESOLVED: initial value of 'flex' is "0 1 auto"
   - RESOLVED: Omitted flex-shrink in the flex shorthand always uses the
               initial value.
   - RESOLVED: Publish Flexbox as LC.

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

   César Acebal
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Ryan Betts
   Tantek Çelik
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii
   Brad Kemper
   Chris Lilley
   Peter Linss
   Divya Manian
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Steve Zilles

<tantek> curious if folks saw this(re: vendor prefixes):
          and they had any thoughts.
<sylvaing> tantek, yes saw it and passed it on Twitter
<sylvaing> tantek, we'll have a blog post on this topic this week
[Scribe's note: This was published later -
  http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web-forward-in-ie10-release-preview.aspx ]

--- Day changed Wed Jun 06 2012

<RRSAgent> logging to http://www.w3.org/2012/06/06-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Jun/0071.html

* sylvaing is pre-emptively relieved the prefixing part of the agenda is
<glazou> eheh
* hober sylvaing++

Unprefixing Transforms, Transitions, and Animations
Scribe: fantasai

   glazou: Unprefixing of transforms, transitions, and animations
   glazou: max 10 minutes
   glazou: Since MS unprefixed these in IE10, is allowing other vendors
           to do that right now.
   glazou: and get status report on the specs
   Tab: I'm morally approving of this move, we should all do it
   Florian: It's painful that they're prefixed, so now cat is out of box, yes.
   dbaron: I think we should unprefix as well. Would also like to see the
           specs move forward.
   glazou: Hearing consensus here. Any objection?
   smfr: Are we making an exception for these specs specifically, or changing
         the policy in general?
   Florian: We're making an exception right now, can discuss the rest later.
   smfr: I'm ok with that then.
   Florian: Are we some strings attached with this permission, or do we assume
            every implementation is good enough?
   glazou: The latter
   plinss: I think everyone's impl should be matching the spec at this point,
           given that I don't see a problem with unprefixing.
   smfr: We're not in a position to object, but MS is asking forgiveness here
         not permission.
   glazou: We did discuss this before.
   Florian: Browser vendors can do anything they want, obviously; question is
            what *should* we do.
   plinss: They can do anything they want, but if they go against WG they're
   plinss: Getting WG to agree means they can ship unprefixed and still be
   ?: Better for PR, maybe.
   plinss: This isn't a change in policy, this is a special exception. We've
           discussed these several times before, didn't have consensus. Seem
           to have consensus now.
   plinss: Still like to get to CR.
   plinss: MS is not going off on a limb and doing things on their own. MS
           didn't quite get permission first, but we're at a place where we're
           ready to give permission anyway.
   smfr: Let's imagine that we discover IE doesn't match the CSS Transforms
         spec when it comes to 3D Rendering section
   smfr: Do we now have to match IE's behavior because it's unprefixed, or
         they have a bug?
   Tab: It'll be standard compat issue -- what decision breaks the least thing.
        Just like 2.1 decisions.
   glazou: IE10 is a preview, right? Still have times to fix things if urgent.
   sylvaing: Yes, some lattitude about that.
   dbaron: Still some open issues in the specs.
   sylvaing: We expect that in some cases we'll match spec, in others might
             be non-conformant against testcases
   glazou: So, resolve? Any objection?
   glazou: I'm hearing no objection, declaring consensus, we're unprefixing
           Transforms, Transitions, and Animations
   <tantek> great!
   RESOLVED: Transitions, Transforms, and Animations may be released unprefixed.

   glazou asks about status of these specs
   sylvaing: Now that release preview is out, will make more time to go through
   sylvaing: Once done with flexbox, want to give priority to those
   smfr: We have 11 open bugs on Transforms, 5 are editorial, 2 are already
         resolved, so 3-4 need more consideration
   smfr: Don't think any big serious issues
   plinss: Good time to push on getting tests for these specs

   florianr: Speaking of tests, when releasing unprefix, is it encouraged or
             required to release implementation report?
   <tantek> normally, unprefixing can happen as soon as a draft enters CR
   <tantek> implementation reports typically come sometime *during* CR.
   <tantek> re: florianr question
   <fantasai> tantek, read snapshot

   plinss: Prefixes was discussed with TAG, and they said we don't have a
           one-document explanation of our policy, both from vendor and
           author perspective
   plinss: Think it's a good idea, publish as WG Note
   <ChrisL> sounds good
   plinss: Sound good to everyone?
   <ChrisL> who will write it?
   <SteveZ> +1 for prefix document
   Florian: Do we want to publish such a note before we debate policy, or
            only after we decide what the new policy should be?
   sylvaing: Don't think any harm in documenting current practice
   <SteveZ> We should document what we have been doing
   plinss: Good to say what we're changing from
   dbaron: If we're going to change it, should publish old and new policies
           together, not leave old one published for a long time
   fantasai: old policy from vendor perspective is documented in snapshot
             and in drafts that follow module template
   fantasai: from an author perspective its not documented
   plinss: Also heard feedback that what's in snapshot is not clear
   <tantek> fantasai - yes, what plinss said (re: snapshot, and your
            suggestion to "read snapshot")
   glazou: Ok, let's do that. Who is going to write the document?
   ChrisL: I'm happy to help for that
   Florian: I'm not sure we agree on what authors are supposed to do
   <nimbu> i am happy to help gather feedback from author side of things
   glazou: Let's write the document, it'll go through this WG and we'll
           discuss it
   plinss: Document gives us a concrete proposal to start with
   Florian: Just concerned we'll spend too much time on that
   plinss: Chairs job to manage time
   RESOLVED: Write document explaining prefixing policy as WG Note.

Box Alignment FPWD
Scribe: TabAtkins

   glazou: Box Alignment, request for FPWD
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012AprJun/0269.html

   fantasai: We all agreed we should work on this.
   fantasai: and there were several decisions that went into flexbox that
             went into the draft.
   fantasai: I want to publish this with Flexbox, because we wanted to make
             it clear that the Flexbox properties will be extended.
   <tantek> I am for publication of the FPWD
   <ChrisL> +1
   fantasai: So I'd like to publish FPWD of Box Align on the same day we
             publish Flexbox LC.
   <fantasai> http://dev.w3.org/csswg/css3-align/
   <SteveZ> +1
   florianr: Good.

   dbaron: What does the current draft say about how it applies to blocks?
   fantasai: Same thing it said in the f2f
   fantasai: [explains what the -content/-self does for Block as well]
     - justify-self aligns the margin box horizontally
     - align-self has no effect
     - justify-content implements HTML align attribute, using 'auto' to trigger inheritance.
     - align-content is like vertical-align on tables; non-auto values make block into BFC

   * glazou notes super-positive feedback from web authors on twitter about
            unprefixing TTA
   <smfr> 3.1 heading says "the ‘box-justify’ property" but the table refers to "justify-self"
   florianr: In the doc you have several parts where you refer to the old
             properties in Flexbox, those need to be updated.
   fantasai: Yeah, I need to make sure a few things is up-to-date.
   florianr: I'm okay with it if those are changed.

   <glazou> this document has the best images in a CSS spec ever :-D
   <ChrisL> Bert is on vacation, I will handle the publication
   <rbetts> I agree with glazou. Super helpful illustrations.

   dbaron: I think it might be important that the doc be a little clearer
           about what the big table with checkmarks mean.
   dbaron: It's saying that these properties handle the other models.
   dbaron: It should probably be clear that the extensions are hypothetical
           currently, but it's still not entirely sure how they'll work.
   dbaron: I just don't want people to try and implement these for layout
           models we haven't discussed yet, based on the little amount of
           information in this doc.
   fantasai: This is a draft, and it does state what happens in the other
             layout models.
   florianr: We agree on the general ideas for how it applies to Block,
             but not yet the details.
   dbaron: Some details seem to have been filled in since the f2f.
   fantasai: It hasn't been changed since then, only changed the names.
   fantasai: Removing block layout just from the overview table doesn't
             make sense.
   fantasai: I can strip the details on block alignment from the spec,
             but that's kindof the point of the spec.
   <fantasai> s/properties/details/
   TabAtkins, Florian: just put in an issue about Block and Table not
                       yet being finished.
   RESOLVED: Publish FPWD of Box Align, with corrections + note about how
             Block and Table interaction is still uncertain.
   * bradk still thinks it is extremely confusing that 'align' means a
           different axis than with 'text-align', and that 'justify' means
           something not even close to the common meaning of 'justify' in
   * sylvaing agrees with bradk. Has had a super hard time following
              discussions due to the terminology.

Scribe: Divya

   <glazou> http://www.w3.org/mid/5F1E71885C2346FAABB7AB84C4AA7E3B@FREMYD2
   TabAtkins: couple of changes I want to make in vars
   TabAtkins: the reason why I presented in the form I did, because it
              required least amount of syntax additions, so we can focus
              on ideas itself
   TabAtkins: I always wanted something similar
   TabAtkins: feedback privately from some people in the group that something
              simpler like a $ sign would be more desirable.
   TabAtkins: changed draft to incorporate that, but it is not permanent
   TabAtkins: var properties are still defined with var-foo, but I would
              prefer it as $foo, the vars are used as $foo.
   TabAtkins: the var() function exists if you want to provide default values
              for vars, and or use parent-var() to refer to inherited values.
   TabAtkins: the big discussion has been going on what kind of syntax
   TabAtkins: some people vocally dislike $ sign and have been playing around
              with other syntaxes
   TabAtkins: I prefer using $ sign for usage, I would like to use $ sign
              for defining variables as well
   glazou: it seems to me $ would conflict with css preprocessors.
   TabAtkins: the maintainer of sass has mentioned that we shouldn't care
              about compatibility of css with sass.
   TabAtkins: there are other languages like using php to write css, in my
              experience it is not an issue.
   TabAtkins: it only happens if you are using string interpolation.
   <tantek> with PHP, just be sure to use single quotes ' ' rather than
            double quotes " " in order to avoid processing of $ variables

   florianr: Three reasons for disagreeing.
   florianr: 1. yes, sass is willing to be fixed, but server-side processing
             languages is an open set.
   florianr: since we have an alternative why break things.
   florianr: 2. I am under the impression that there is a large overlap
             between people who want to use $ and the set of people who
             think we should use $ in property names and places other
             than values.
   florianr: because these variables behave differently, it is a /good/
             thing they look different
   florianr: 3. you would introduce another function to do var defaulting
             or inheritance. If we have to have a function anyway, I would
             just have that syntax rather than multiple mechanisms.
   florianr: the way it was initially proposed, still look best to me.
   <fantasai> florian++
   <tantek> tabatkins++
   <bradk> Let's use the euro symbol instead of the dollar sign.
   <sylvaing> bradk, that's still a currency symbol? *cough*

   TabAtkins: if people are confused they will immediately realise that it
              doesn't work.
   florianr: it doesn't mean that they would immediately understand why
   TabAtkins: it is not even confusing, you define a variable it looks like
              this, if you try to use variable as property name, it is not
              something that is possible to confuse
   florianr: it is possible to be confused not be misused.
   <tantek> I agree that any such confusion would be brief.
   fantasai: Is the goal to summarize or to decide?
   fantasai: It seems the discussion has been summarized.
   glazou: Lets move on.

Scribe: TabAtkins

   <glazou> http://wiki.csswg.org/topics?datasrt=&dataflt[]=spec%3Dcss3-flexbox

   <fantasai> http://wiki.csswg.org/topics/flex-initial-value
   fantasai: First is to discuss the initial value for the 'flex' proeprty.
   fantasai: Ojan was unhappy with our f2f decision to make items flexible
             by default.
   fantasai: The thread produced three possibilities - one we rejected in
             hamburg, one we accepted, and a third one that seems to have
             consensus now.
   fantasai: The issue is that, if the items are inflexible by default,
             you can either use the alignment props, auto margins, or flex,
             and all of these are one step away.
   fantasai: The disadvantage is that if you don't have negative-flex by
             default, you'll run into overflow situations in a lot of cases
             where you weren't thinking about narrow screens.
   fantasai: So having negative flex on by default protects users somewhat.
   fantasai: Another disadvantage is that, in the cross direction, the
             default is "stretch", which is like flexing, so it would be
   fantasai: We talked about this on the list, and it turns out you get more
             pros and less cons if you make the initial value "0 1 auto",
             inflexible in growth situations but flexible in shrink situations.
   fantasai: The only con that's left is that it's inconsistent with "stretch"
             in the cross dimension, but that doesn't seem to be a big deal.
   fantasai: The mailing list seems to mostly lean toward the new behavior.
   TabAtkins: Among the implementors and editors, there were no strong
              objections, one favoring current behavior, and the rest
              favoring new behavior.

   alexmog: I have one problem with the new defaults - there is no keyword
            for whatever this is.
   alexmog: I think if we like this, we should have a keyword for it.
   fantasai: You mentioned that the keyword for that is "initial".  We can
             put it into the "common values for flex" section.
   <fantasai> http://dev.w3.org/csswg/css3-flexbox/#flex-examples
   <fantasai> "flex: initial"
   alexmog: Usually the smart default is called "auto". If that's not
            applicable here, maybe we shouldn't add it.
   fantasai: It's important to make it easy to get relative flex - it should
             be 1 keyword.
   alexmog: It might work if all of these defaults remain defaults in flex
   alexmog: So "flex:auto" means "0 1 auto", while "flex:1" means
            "flex: 1 1 auto".
   antonp: I think I agree here.
   antonp: There's no reason your shortcut can't be a bit clever.
   fantasai: We already do some magic - "flex:1" sets flex-basis to 0..
   fantasai: I would rather have the basis set by itself consistently set
             flex to 1 instead of having the "auto" keyword set it to 0.
   alexmog: I just think that too much magic makes it difficult to use.
            I'd much prefer shorthands to set what I specify, and use
             defaults for whatever I don't specify.
   fantasai: I like the current shorthand behavior.
   alexmog_: But not the initial values?
   fantasai: I think the initial values could possibly change.  But I think
             this is limited magic.  If you set only the flex-grow, it gives
             a special flex-basis.  If you set only the flex-basis, it gives
             a special flex-grow. That's it.
   alexmog: Pretty much every use of flexbox I've seen has flex explicitly
            specified on every element.
   alexmog: If they want default behavior, they'll have to remember how to
            set that.
   fantasai: They just use 'initial'.

   <sylvaing> do we use initial anywhere else right now?
   <TabAtkins> sylvain, it's a global keyword. ^_^
   <sylvaing> yeah, but does anyone support it?
   <sylvaing>  sure don't see it in stylesheets
   * glazou has the impression we're running in circles here
   * sylvaing glazou, technically it's a cycle()

   fantasai: I think authors will just learn to use "initial" here for
             this behavior.
   <sylvaing> does not like depending on a keyword that is totally new
              for most authors and is not well supported elsewhere
   <sylvaing> "just use this global keyword that...doesn't really work
              anywhere else for now"
   alexmog: I don't think anyone is really against it - I'm just slightly
            uncomfortable with new defaults.
   antonp: Someone said on the mailing list that shouldn't the default be
           "do very little"?
   fantasai: We rejected that - having negative flex on by default helps
             users when the author wasn't thinking about things like narrow
   alexmog: If we don't have it stretch by default in the main axis, could
            we change back to 'start' for cross-alignment?
   TabAtkins: It was that way - I changed it to 'stretch' based on your
              feedback that we should be consistent with the old draft.
              I'm fine either way.
   florianr: One debate at a time, please?

   Straw Poll Options:
     A: Keep current behavior (initival value of flex is "1 1 auto").
     B: Change current behavior to be non-flexible by default (initial value of flex is "0 1 auto")
   <stearns> abstain (if we take votes by IRC as well it could go faster)
   <fantasai> Ojan and dholbert on the mailing list chose B
   <nimbu> abstain
   sylvaing: A
   glazou: abstain
   plinss: abs
   tantek: abstain
   ChrisL: abstain
   fantasai: B
   antonp: abstain
   dbaron: abstain
   arronei: abstain
   hober: abstain
   CesarAcebal: abstain
   * ChrisL abstain is winning!
   Rossen: A
   rbetts: A
   TabAtkins: B
   smfr: abstain
   bradk: abstain
   <tantek> ChrisL - abstain winning = leave to editor's choice IMHO.
   florianr: B
   alexmog: A
   glenn: abstain
   * ChrisL editor deathmatch, excellent
   * sylvaing flex: abstain; // engine picks something
   glazou: The people who want A, can you live with B?
   <rbetts> I can live with B.
   RESOLVED: initial value of 'flex' is "0 1 auto", editors to decide details
             among themselves.

   <fantasai> flex: 0 1 auto
   <fantasai> flex: 0 auto
   <fantasai> http://wiki.csswg.org/topics/css3-flexbox-default-shrink-when-grow-is-0
   fantasai: Request was to make a flex value of "0" be special - instead
             of setting flex-shrink to 1 (its initial value), set it to 0
             as well.
   fantasai: Given the choice we just made, I think we should reverse that,
             and make omitted flex-shrink always take its initial value.
   Alex: makes sense
   RESOLVED: Omitted flex-shrink in the flex shorthand always uses the
             initial value.

   fantasai: Publish Flexbox as LC?
   TabAtkins: We're okay with the remaining issues.
   <tantek> go LC!
   RESOLVED: Publish Flexbox as LC.
   <nimbu> HURRAY

Meeting closed.
Received on Wednesday, 6 June 2012 20:29:17 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:16 UTC