- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 27 Jun 2012 15:08:39 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: All elements, regardless of 'display' value, are
promoted to being flex items when placed in a flex
container.
- RESOLVED: calc inside calc allowed
- RESOLVED: publish updated CR of CSS3 Backgrounds
- Discussed edits to CSS2.1 wrt "formatting context" terminology,
and whether 'overflow' applies to table elements.
Note: 4th of July telecon is *not* cancelled.
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David baron
Ryan Betts
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Alex Mogilevsky
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
David Storey
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/06/27-css-irc
Scribe: Florian
Administrative
--------------
glazou: I'll be away for 3 weeks, and peter also on the 11th of July
glazou: suggested replacement chair: Chris
glazou: next call is on US Independence day, can we have a call?
many: yes
Transforms, transitions, animations
-----------------------------------
smfr: on transform, update from last week:
smfr: IE and mozilla don't transform the background with attachment
fixed
florian: opera is transforming the background, and scrolling it in
in parallel with the element, not parallel with the page
smfr: IE and mozilla do that too
dbaron: IE and moz draw the background as if there was no transform,
and then transform
smfr: if you use the transform to flip things upside down, the
background is going to scroll backward, which is weird
dbaron: they should put the background on an ancestor
dbaron: it is ok, as fixed background are really meant for the root
elements
florianr: agree, we don't care too much about what happens on
non-root elements
smfr: should we define it then
florian: not expected use case, but will probably be used, so we
should define
dbaron: we should define, to avoid people depending on a behavior
we wouldn't want
smfr: I would prefer to define it in a way that means you don't
have to repaint the background when you scroll the page
dbaron, tab: sounds acceptable
ACTION smfr write a proposal about fixed background and transforms
<trackbot> Created ACTION-481
glazou: anything else?
smfr: there is a little terminology issue, relating to containing
blocks
smfr: very tricky, would appreciate any help on fixing it
sylvaing: animation, still 46 bugs
dbaron: no news on transitions, still have to go through the hard
issues
Flexbox
-------
Scribe: Sylvain
<glazou> http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
Tab: still like proposal A
florian: the reason I don't like A is that it's inconsistent
florian: what happens with regular elements differs from what happens
to the special-cased elements
florian: for buttons et al. you can't turn this behavior off
* fantasai is happy with anything except C
florian: either we need an opt out and B is fine, or we don't and D works
tab: D is not very flexible.
tab: B is more work that seems necessary
* alexmog is unhappy with anything except C
tab: A special-cases elements because these elements are special cases
tab: other document languages might have such cases but there is no
good way to address this without defining new concepts
smfr: could we make anonymous flex item containers for these elements?
tab: in some cases this wouldn't work well e.g. the anonymous container
would be stretched but not its content
glazou: many diverging opinions, it's time for a straw poll
<glazou> http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
florian: B or D (no objection to others)
rbetts: abstain
glazou: D
alexmog: C then D ... and not A
stearns: not A
sylvaing: abstain
koji: abstain
brad: D
dstorey: abstain
plinss: C, not A
rossen: C and then D, not A
arronei: not A
johnjan: C
antonp: prefer B or D, not C
smfr: abstain
glenn abstain
szilles: abstain
dbaron: abstain
tab: A or D
hober: abstain
fantasai: not C
<fantasai> sounds like we can eliminate A
glazou: let's straw poll C vs. D
florian: D
rbetts: D
glazou: D
alan: abstain
sylvaing: C
koji: abstain
brad: D
dstorey: D
brad: D
plinss: abstain
rossen: C
arronei: C
john: C
antonp: D
smfr: C
glenn: abstain
szilles: abstain
dbaron: D
tab: D
hober: abstain
alexmog: C, but ok with D
fantasai: D
* bradk doesn't like 'display: flex-item'
fantasai: Several "not C"s, but no "not D"s
RESOLVED: Proposal D for handling of replaced elements as flexbox items
Formatting Contexts (2.1)
-------------------------
Scribe: fantasai
<glazou> http://wiki.csswg.org/topics/overflow-formatting-context
antonp: Just waiting for review from a couple people on this
antonp: haven't heard back from dbaron
florian: resolution was accept unless dbaron says no
dbaron: you should just go ahead without me
antonp: Rossen replied on the list, haven't heard back after response
Values and Units: vmax
----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012May/1198.html
fantasai: We have vmin, request was to add vmax
hober: Are their use cases?
tab: person posting didn't give a precise example, but did say there
were some
florian: if you think of it as cover vs contain, makes sense
tab: Once you have vmin, vmax is trivial
RESOLVED: Add vmax
http://lists.w3.org/Archives/Public/www-style/2012Jun/0446.html
* hober Yo dawg, I heard you like calc(), so I put a calc() in your
calc() so you can do math while you do math
* sylvaing we need to calc deeper
florian: calc() inside calc() makes sense to me
florian: unless we want to open debate of whether calc exists at all
and just use bare parens
glazou: Are there any objections to calc() inside calc()?
silence
RESOLVED: calc inside calc allowed
fantasai: the other issue that's open is precision
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
fantasai: I think Tab and I whiteboarded a proposal, but I don't know
where it is.
fantasai: Don't think this should hold up CR, though
florian: agreed
CSS3 Background
---------------
fantasai: wanted to update the CR, dbaron had an issue on animations
line
fantasai: seems like a lot of mostly redundant info, was wondering
if we can keep that in the transitions spec
dbaron: yeah, can probably keep in transitions spec
florian: There are a number of background properties that take a list
florian: if there are fewer than images, then repeat the list
florian: computed value is as specified
florian: ... trigger a transition
florian: does adding to the list trigger a transition, even if no
layers are added?
Tab: It would be a null transition
florian: would send out events, though
florian: Seems more natural for computed value to reflect the value
we're using in theory
fantasai: would you truncate the specified value if it's too long then?
florian: yes?
dbaron: i think this is too late to change it
dbaron: we do this computed value line across 3-4 specs now
dbaron: too late to change them
fantasai: if no one has other changes to make, suggest publishing
update to CR
florian: Another question...
florian: background-position, syntax where you say 'right 10px'
is equivalent to 'calc(100%-10px)'
florian: probably too late to change that though
florian: Mozilla shows that in its computed value
fantasai: that's incorrect per spec...
RESOLVED: publish updated CR of CSS3 Backgrounds
CSS2.1 Formatting Contexts reprise
----------------------------------
Rossen: Just read anton's reply
Rossen: My issues with the proposal was the fact that when you read
2.1 sections 9.2.1
<Rossen> http://www.w3.org/TR/CSS21/visuren.html#inline-boxes
Rossen: talks about when an inline level box is created
<Rossen> http://www.w3.org/TR/CSS21/visuren.html#inline-formatting
rossen: inline-table and inline-block generate inline-level boxes,
which participate in inline formatting context
rossen: we have 9.... that talks about inline formatting context,
but doesn't say what establishes it
rossen: neither 9.4.2 nor 9.2.2
rossen: Because of this I can easily deduce that an inline formatting
context can be created by an inline non-replaced element
rossen: issues I raised would become a problem
rossen: ok with proposed definitions, as long as we take an action
to clarify exactly what you said
rossen: and state when an inline formatting context is created
rossen: want to be assured that an inline elements don't establish
an inline formatting context
fantasai: "An inline box is one that is both inline-level and whose
contents participate in its containing inline formatting
context." (9.2.2)
fantasai: implies that the inline box doesn't create an inline
formatting context for its contents
rossen: if we add to beginning of inline formatting context
"inline formatting context is established by ...." then
there will be no ambiguity
antonp: "A block container box either contains only block-level
boxes or establishes an inline formatting context and
thus contains only inline-level boxes."
antonp: before nothing said what establishes an inline formatting
contexts
antonp: I understand your concern that it's not 100% clear that an
inline box does /not/ establish an IFC
rossen: if that's clarified, then all my concerns are invalid
rossen: so if we're ok with adding this clarification, then I don't
have a problem
rossen: there's a behavior difference...
rossen: it appears that Gecko has overflow for table
antonp: according to the email, behavior is 50/50
antonp: among 4 key implementations
antonp: Øyvind sent an email that there's a difference as to whether
overflow is applied to table box or table wrapper box
fantasai: so do we accept the edits or no?
rossen: I'm ok with this
rossen: concerned about change of behavior in implementations
antonp: Isn't it the case that IE won't have to change?
rossen: IE as of 9 and 10 will have that change
rossen: I guess we didn't see any records that this is breaking
anything when we changed it
-smfr
florian: if we have implementations on either side, defining behavior
of table is something we should do anyway
rossen: only question is, do we want scrollers on tables or no?
rossen: should we accept this, then?
rossen: anyone object to overflow on tables?
rossen: curious about other implementers
dbaron and florian don't know
dbaron: I'd need to look into it.
tab: I know someone does overflow on <tbody>
dbaron: I believe we stopped doing that, but I'm not sure
rossen: easy enough to call it out explicitly as either yay or nay
wrt overflow
rossen: my proposal is to go with majority of implementations
fantasai: so we have an action item to figure out what that is
<fantasai> http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/
glazou: ok, will deal with that later
Meeting closed.
Received on Wednesday, 27 June 2012 22:09:09 UTC