- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 11 Jul 2012 12:13:44 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Negative durations are invalid for transitions/animations
- RESOLVED: move feature requests for new animation APIs to Level 4
- RESOLVED: Defer the <ident> type until Level 4 of V&U
- RESOLVED: the request to make a change is rejected; "calc" is required
- RESOLVED: spaces are required around addition/subtraction operators;
no change from previous resolution
- RESOLVED: DoC for css3-values is accepted; move spec to CR
- RESOLVED: Flex items do not create a pseudo-stacking context at this
point
- RESOLVED: non-auto values of z-index create a stacking context on
flex items even without 'position: relative'
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Ryan Betts
Bert Bos
Elika Etemad
Simon Fraser
Sylvain Galineau
John Jansen
Chris Lilley
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/07/11-css-irc
Scribe: SteveZ
No Additions to Agenda
Animations Issues
-----------------
Sylvain: Sent call for consensus to make negative duration be invalid
<smfr> sounds fine
Sylvain: this should have no impact
RESOLVED: negative durations are invalid
<smfr> no
<oyvind> (hm, is "transition: -2s 1s" invalid? might want to clarify that)
Sylvain: Level 3 Animations are becoming unprefixed, so think we
should defer requests for new DOM APIs
RESOLVED: move feature requests for new APIs to Level 4
Smfr: Should these be prefixed if an implementation is done in the
next few months?
Sylvain: yes, they should be prefixed
Sylvain: if something is not yet specified then it should be prefixed
when implemented
plinss: We can make L4 additions short and advance that quickly.
Values and Units
----------------
<smfr> http://dev.w3.org/csswg/css3-values/issues-lc-2012
Fantasai: Propose to defer resolving the case issue on idents
(CSS and User defined) until level 4
<fantasai> by deferring the definition of <ident>
smfr: worried that animations may start having user ids and would not
like to see these being different
fantasai: deferring does not mean not working on it; it means resolving
the issue in conjunction with the active specs, like animation
fantasai: This means removing the type from V&U from Level 3; CSS 2.1
has its own definition for counters
fantasai: We can work on solving the issue for Animations and Counter
Styles, but inline the definition until we factor it out
in css4-values
RESOLVED: Deferring the type until Level 4 of V&U
<dbaron> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-36
Issue 36: removing "calc" and using bare parens
Florian: stay with what we have and require "calc" part of "calc()"
Tab: Does the working group agree with the editors request to reject?
Multiple people say they prefer calc()
Florian: fantasai preferred parens?
Fantasai: I prefer just using parens, but do not object to requiring
"calc" if that's the WG's preference
RESOLVED: the request to make a change is rejected; "calc" is required
<nimbu> (what would bare calc look like?)
<hober> nimbu: (10px + 10%) instead of calc(10px + 10%)
<dbaron> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-35
<fantasai> Issue 35, changing tokenization of DIMENSION so units can
no longer contain - so that white space can be dropped
between +/- and operands
Tab: there may have been prefixed units in the past and this change
would invalidate this
dbaron: This is one of the top author complaints about calc(), it trips
up a lot of people who don't understand why it doesn't work.
dbaron: I'm inclined to say we should try to fix it
dbaron: It means we'd have a problem with keywords that have hyphens
in calc(), things like min-content
Tab: I really want to extend in that direction
Florian: It would make the grammar more complex, but we could work around
it by having different parsing rules for numeric and keyword types
<ChrisL> that is why SVG had camelCase property names (except for ones
already defined by CSS) - to avoid the hyphen being seen as a minus
* sylvaing agrees with dbaron that it is a major stumbling block when
learning the feature
Tab: This would require different tokenization for calc
Florian: This is not a huge deal
Tab: there is only one unique tokenization today: that is an+b for nth child
Florian: the Opera lexer is already context sensitive
* fantasai suggests not trying to figure out exact changes on this call
<sylvaing> +1 to fantasai, dbaron
* ChrisL agrees, send in a concrete proposal in email
dbaron: OK with rejecting change because I do not have an answer for what
to do
Tab: We could conceivably change this in the future
Sylvain: Sensitive to the usability issue, but this is not the time to
make a change. We need a proposal to make it work
Florian: this can be fixed in the future without breaking existing documents
Sylvain: users can tell that their calc expressions do not work so they
should not be confused about what is failing
Fantasai: Note, such a change wouldn't break forwards compat of a style
sheet, but would affect backwards compat.
fantasai: Existing browsers (e.g. IE10) do require the spaces;
if we change it later, someone will write calc() without
spaces (e.g. for IE11), and it won't work in older browsers.
They won't expect there to be a problem because IE10 supports
calc(); the change in allowed syntax that makes it not work
is very subtle.
Sylvain: either way we decide, IE10 is not going to change here
RESOLVED: spaces are required; no change from previous resolution
Bert: need to send followup email to the response to issue 22, since the response is no longer correct
<ChrisL> agree that it is minor but needs to be closed off properly
ACTION fantasai send followup to v&u issue 22
<trackbot> Created ACTION-483
Bert: on Issue 22 there is a message that says the resolution is 27 bits
and we have changed out mind so there should be a message to say that
RESOLVED: The DoC is accepted (as edited re issue 22 above)
<ChrisL> yay
RESOLVED: V&U is taken to CR
Administrative
--------------
PLinss: Expect to have a final venue by the end of this week for the
San Diego meeting
<dbaron> I might be more likely to join an event on Sunday than on
Thursday, but it's somewhat uncertain. (I may well have a
bunch of meetings to call in to on Thursday and Friday.)
PLinss: Trying to put an event (Sailing) on Thursday; HP will contribute
some, but we would need to pay to participate
<ChrisL> my regrets for san diego
* sylvaing suspects plinss meant Tuesday since the meeting is Monday-Wednesday
* plinss meant Thursday… we'll be actually working Tuesday :-)
Flexbox
-------
<fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
<sylvaing> THERE WILL BE NO MORE PROPERTY RENAMING
Painting Order
<fantasai> Issue #5
<fantasai> http://wiki.csswg.org/topics/flex-item-painting
Issue 5: Painting order: blocks and table cells vs inline blocks
alex: I think this is a more generic question, not specific to flexbox
alex: applies e.g. to grid as well
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Jul/0257.html
alex: is every new layout model use pseudo-stacking context?
Alex: DBaron do you want it to behave like floats
dbaron: I have mixed feelings about it. Would have been better if we
did that originally, but maybe better to have inline-* does
it and other things don't
fantasai: that would decide flexbox vs. inline flexbox, but doesn't
tell you about items wrt each other
alex: float behavior is special, it's different from text
alex: above text or below text
alex: others are things that may overlap due to negative margins, etc.
alex: vertical flexbox is similar to block flow, if it makes sense
for block would make sense for flexboxes
Fantasai: The behavior here is weird because floats needed to be above
the background of items that were later in the doc tree
alex: would help to have a use case that would make a difference one
way or another
DBaron: I do not have a use case that would distinguish either way
Fantasai: I cannot think of a single use case that would be better with
block behavior, but I can imagine some where pseudo-stacking
would be better
fantasai: so based on that I would say it should be a pseudo-stacking
context
?: Can you give an example?
Fantasai: I have a flex-box with a bunch of cards that overlap a bit
and I open up one that the user is hovering over
fantasai: would want the text of each card to be right over its bg,
not over the bg of the card on top of it.
Anton: I think it makes sense to make flexbox a pseudo-stacking context.
Anton: In block layout, you don't really see the individual blocks,
you see the content as a continuous flow. So the painting behavior
there makes sense.
Anton: In the new layout models, we are going to view the pieces as
basically independent of each (say in grid)
Anton: I have yet to grasp the range of use case for flex-box and cannot
yet see how flex-box should behave:
Alex: I propose moving this issue to grid and then use what we decide
there back to flex-box
Alex: I do not think that there are a lot of cases for overlapping items
in flex-box; for grid on the other hand we do want overlapping items
fantasai: I think for grid, if you expect to have overlapping, then you
*really* want them to be pseudo-stacking contexts
alex: So let's resolve for both grid and flexbox as pseudo-stacking
contexts
<dbaron> So it sounds like we're converging on Proposal B.
Anton: it is the safer way to go with the pseudo-stacking behavior
PLinss: we cannot envision all the use cases so we should not make
decisions based on what we can see.
PLinss: I can see people wanting the behavior in both ways
PLinss: I think the behavior is controllable
Florian: we are just discussing the default behavior
Anton: It's already controllable with position:relative
fantasai: This relates to issue 16, on whether z-index should just work
on flex items
<fantasai> auto would have no effect
<fantasai> integer would mean form a stacking context
<fantasai> note, that this only lets you switch into having a stacking
context vs not, can't switch between pseudo-stack or not
Fantasai: That would give a switch for stacking context, but not
pseudo-stacking context
Florian: I'm leaning towards No, not pseudo-stacking context. Yes,
z-index just works.
DBaron: I cannot think of any case where a user wanted that behavior
rather than accidentally depending on it
Alex: I cannot think of any such case either, but am not sure there
would not be one
* sylvaing this discussion assumes the scope of use-cases to be known
AND that users understand stacking.
Alex: I would leave the current definition (agreeing with Florian)
because we know what it does and do not have examples that show
a need to change
RESOLVED: no pseudo-stacking context at this point; z-index creates a
regular stacking context
Anton: User were taught that z-index only works with relative positioning
and this changes that rule
Anton: This is more of a cognitive (mental model) problem than a
practical problem
Florian: This is not a new problem, however.
Issue 12
alex: Need to use max(min, basis) for wrapping
Tab: size used for line wrapping is clamped by min and max
Alex: If you have a bunch of buttons, if there is space, then they
should go to the next line; if not enough space, then shrink
Tab: we should examine more intelligent controls in level 4
RESOLVED: No change for Issue 12
Tab: one more issue to resolve to go to CR
Florian: No, we also need a new name for 'order'
Tab: I object to change of the name, "order"
Florian: We resolved last week to change the name of "order"
Tab: I OBJECT to such a change
<sylvaing> +1
Florian: please add the topics I mentioned last week to next week's agenda
Meeting Adjourned at 10:03
Received on Wednesday, 11 July 2012 20:38:26 UTC