- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 06 Jun 2012 13:28:43 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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):
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/itl6mtx2dxI
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
time-boxed...
<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
non-conforming.
plinss: Getting WG to agree means they can ship unprefixed and still be
conformant.
?: 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
issues
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?
yes
<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
'text-align:justify'.
* sylvaing agrees with bradk. Has had a super hard time following
discussions due to the terminology.
Variables
---------
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.
Flexbox
-------
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
inconsistent.
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
contents.
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
screens.
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