W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[CSSWG] Minutes Tokyo F2F 2013-06-06 PM III: Reversing Transitions, Parens and Escapes, Alignment

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 22:57:14 -0700
Message-ID: <51D3BD3A.3050400@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Parens and Escapes

   - RESOLVED: MQ requires white-space on both sides of a parenthesis

   - RESOLVED: Idents followed by open parenthesis must have white space
               between the two unless it's a function.

   - RESOLVED: String and URL types for attr() literally takes the
               attribute's value without parsing; CSS escapes are not


   Tab and fantasai presented the new Alignment spec
   explaining changes in design and details.

   RESOLVED: Need more work on baseline section, define first-line and
             last-line baseline for all things.


   RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.

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

Reversing Interrupted Transitions

   dbaron: Haven't quite finished my test case
   dbaron: one algorithm and one proposal implemented, still need to impl
           the other one.
   dbaron: in javascript
   dbaron: Don't leave the page open in a tab after using it!
   plinss: Let's get back to that.

White Space in Media Queries

   SimonSapin: We had an issue in both MQ and @supports
   SimonSapin describes the issue
   SimonSapin: The grammar had optional white space, meaning that if you
                used a comment to separate the tokens, it would be correct
   SimonSapin: reader may not know this detail
   SimonSapin: We changed the grammar to allow whitespace, like calc()
   SimonSapin: Issue is resoled in @supports, but still exists in MQ.
               We should make the same change, but we have to wonder
               about compat.
   dbaron: I don't worry about compat.

   TabAtkins explains on whiteboard
   TabAtkins: @media screen and/**/(color) — is that correct?
   SimonSapin: With the current spec, and(color) looks correct, and it is not
   TabAtkins: This problem applies to every ident in a parenthesis that can
              be next to each other without being a function
   dbaron: This is the problem with the function token
   SimonSapin: Can use the function token in the grammar, but that is more
               complicated. Don't want to do that.
   TabAtkins: Agreed.
   SimonSapin: decided not to do function tokens in @supports
   glazou: Shall we adopt SimonSapin's proposal?
   glazou: require white-space in MQs

   TabAtkins: This will come up every time we have parentheses
   plinss: As long as you have some token between, should be valid.
   plinss: But want it to be consistent.
   glazou: People expect it to work, because it's * in the grammar.
   Bert: Can just add a comment in the grammar.
   plinss: But have to do it everywhere. But I don't feel strongly about
           and(color). Just want it consistent.
   glazou: Why is white-space required in @supports?
   TabAtkins: To avoid that removing a comment changes the meaning.
   SimonSapin: @supports now requires white-space on both sides.

   plinss: Need to adopt this anywhere we have parens.
   glazou: Not everywhere, just when it's not a function.
   plinss: Don't want white-space in nested parens.
   TabAtkins: Any time an IDENT is next to a parenthesis, we require white-space.
   plinss: on the outside of either parenthesis.
   RESOLVED: MQ requires white-space on both sides of a parenthesis

   Bert: Don't require it in the font shorthand
   Bert: basically the same case.
   Bert: If you have the font shorthand. "font: Times/**/10pt" is fine,
         but omit comment is not.
   plinss: Times10pt becomes one item
   SimonSapin: If you aren't familiar with the tokenizer, it's much more
               understandable than with parentheses.
   Bert: But we're talking about consistency
   plinss: Really only an issue with parentheses.
   Bert: An issue with all tokens with more than one character. Also with
         the ~= or the ||.
   plinss: That's an interesting change, going back to syntax.
   plinss: if the attribute matcher becomes one token if they had a comment
           between before
   plinss: that's a functional change.
   TabAtkins: A precedent of ignoring comments in weird places.
   plinss: They kind of deserve it.
   Bert: I guess I'm not sure which is better, but doesn't seem like a big
         problem at the moment. Can't see the big story yet.

   TabAtkins: Where would we define this?
   TabAtkins: Values and Units?
   TabAtkins: because it changes the prop grammar.
   plinss: Syntax?
   plinss: it's a fundamental thing.
   TabAtkins: Don't want a resolution that requires us to re-ask about it.
   RESOLVED: white-space between any IDENT an the outside of a parenthesis.

   SimonSapin: The proposal was to require white-space on both sides.
   plinss: Yes, do that everywhere
   TabAtkins: That's what we require in @supports.
   <SimonSapin> plinss: yes, both )<ident> and <ident>(
   Bert: Just came to mind: can make 'and' a keyword, so it can be followed
         by paren.
   TabAtkins: The issue is not related to 'and' specifically.
   TabAtkins: Anytime you have keywords next to parens.
   TabAtkins: Anytime a paren is valid by itself and an ident is valid next
              to it.
   TabAtkins: One example is in grid syntax, if we switch to named line syntax
   TabAtkins: (x y)auto needs white space.
   TabAtkins: so no tightly-bounded set of keywords.
   TabAtkins: All parentheses, or just naked parentheses? what about an ident
              following a function?
   TabAtkins: function, the concept, not the token.

   plinss: could it be a compat risk?
   plinss: ident after function.
   fantasai: Yeah, gradient followed by length in background shorthand.
             A likely typo.
   plinss: So we can't require it everywhere.
   TabAtkins: So only naked parenthesis groups.
   plinss: We don't have naked parentheses anywhere else, so not a problem
   dbaron: We have it inside calc()
   TabAtkins: But you never have an ident.
   TabAtkins: Need a delim, no implied multiplication.
   fantasai: One reason why we feel it's awkard and want symmetry in MQ
             and @supports is that they are conjunctions.
   fantasai: I'm happy if we just require it for conjunctions.
   TabAtkins: If we did that, and didn't care about end parens, we could
              just make the parser recognize and( as a function token.
   Tabatkins: dropping the comment.
   TabAtkins: and be invalid.
   plinss: I guess that's fine
   TabAtkins: Can handle it either way
   plinss: No, I don't think that's fine.
   plinss: url/**/( is not a URL token
   plinss: That would turn it into a function.
   plinss: making it valid.
   TabAtkins: Handle it as grammar then.
   plinss: idents followed by open parenthesis must have white space between
           the two unless it's a function.
   RESOLVED: (replaces previous resolution) Idents followed by open parenthesis
             must have white space between the two unless it's a function.

CSS escapes in attr() values

   SimonSapin: attr() defined in the values spec
    SimonSapin:This function now takes a parameter with expected type
   SimonSapin: can pass integer etc.
   SimonSapin: In the defining for string and url, we say that the absolute
               value is passed
   SimonSapin: should clarify whether CSS escapes are interpreted, and I
               think they should not be.
   SimonSapin: If they need to be serialized, we may need to add escapes,
               but that's a separate concern.
   TabAtkins: att="foo\33", content: attr(att) displays "foo33" or "foo\33"?
   plinss: Don't want to move escapes from one context to another.
   plinss: it should be resolved before.
   glazou: Entities should not leave their context.
   RESOLVED: String and URL types for attribute literally takes the attribute's
             value without parsing.
   <SimonSapin> In particular: clarify that no CSS escaping is involved.
                Probably remove wording like "parsed as the contents of a
                CSS <string>".


   TabAtkins explains concepts, but not the basic properties
   TabAtkins: This applies flexbox alignment props to rest of CSS

   fantasai: Most keywords are axis agnostic, so put them in a separate section
   TabAtkins: Only non-obvious are self-start and -end
   TabAtkins: start/end are defined based on the mode and directionality
              of the parent element
   TabAtkins: self-start/end are defined based on the element itself.
   TabAtkins: flex-start and -end are based on the flex directionality instead of the writing ode
   dbaron: Do flex-start and -end fall back?
   fantasai: to start and end.
   fantasai: if not flexbox

   fantasai: we have left and right, because sometimes you want that, but
             we can't always fulfill that if it's in the wrong axis.
   TabAtkins: Helps explain <div align="...">

   fantasai: stretch depends on the layout mode, defined further down
   fantasai: We pulled the baseline definition from 2.1 and put it here.
   fantasai: Flexbox also has it
   dbaron: doesn't distinguish between inline-block and [...]
   fantasai: defined to use last-line baseline in 2.1
   fantasai: Need to spec first-line baseline and last-line baseline
   fantasai: and which are used for different things.
   fantasai: first-line and last-line baseline interaction is complicated,
             so need to define based on context, and research it.
   fantasai: Don't expect impls to be sensible.
   RESOLVED: Need more work on baseline section, define first-line and
             last-line baseline for all things.

   fantasai: Block-axis of table is undefined.
   fantasai: Table with a block of text inside, with a vertical text context,
             then the block axis will align with the inline axis
   fantasai: Need a concept of baseline for each box
   fantasai: Is it based on the baseline of the first column, or does it
             not have a baseline?
   TabAtkins: No testing yet
   fantasai: Basing on first column makes sense
   Bert: Why not center?
   fantasai: if you want that, then you would center it.
   TabAtkins: There is a keyword for that.

   fantasai: We'll do another pass, but needs review eventually.

   fantasai explains distributed alignment
   TabAtkins: space-evenly is new, based on requests to flexbox
   fantasai: Useful for two-column layout with different layout models in each
   TabAtkins: 'stretch' came from Grid Layout.
   fantasai: Needed for flex lines.
   fantasai explains overflow alignment

   fantasai explains justify-content and align-content
   dbaron: not handled the same way as the 'align' attributes?
   TabAtkins: We have special keyword.
   dbaron: People have trouble following, not really working as an introduction.
   TabAtkins explains justify-items
   TabAtkins: can choose legacy behavior
   dbaron: My issue was with how you mapped HTML alignment attributes that
           don't have a BFC.
   fantasai: Vertical alignment in the vertical axis forces a BFC.
   fantasai: but might need thinking about
   fantasai: might also need horizontal axis.
   TabAtkins: Can only use the block-axis one on blocks
   TabAtkins: Get <center> behavior by using legacy keyword
   TabAtkins: The property that does that does not have the BFC behavior

   Bert: 'safe' and 'true' centering…
   Bert: I want to reintroduce true centering in text-align, even where
         there's overflow.
   Bert: and margin: auto, where I want centering without clamping
   fantasai: This spec takes those props and applies them to all box models
   TabAtkins: Don't use margins to center. Use align property to choose true
   fantasai draws case with shrink-wrapped table with margins and centering.
   fantasai: Want at least a certain margin, but also want centering.
            This is a better model for that, using justify-self.
   fantasai: have cake and eat it, too

   fantasai: justify/align applies to block/inline.
   SimonSapin: block-align and inline-align?
   TabAtkins: Flexbox doesn't care about your writing direction
   TabAtkins: prop names are not renameable.

   TabAtkins: Need to discuss abspos
   Bert: Can I use other props in the normal flow?
   TabAtkins: Can align the entire block's contents
   TabAtkins: It's defined in the spec.
   fantasai: Vertical centering: use align-content on an element
   TabAtkins: Spec is split into two axes and three alignments applied to them
   Bert: last column "Applies to" answers my questions.
   Bert: Have to rewrite Box Model

   Rossen: These apply to border box or margin box?
   fantasai: Margin boxes.
   TabAtkins: In case of vertical-aligned paragraphs, the outermost bounding
              box of the contents.
   Rossen: justify-self: true center on box with 25% width and 50% left margin,
           will be centered with the margin box?
   TabAtkins draws on board
   Rossen is satisfied

   TabAtkins: Let's talk about abspos
   fantasai: The plan of this draft is to make it easy to center things,
             including abspos
   fantasai: The containing block for your asbspos item has offsets specified
   fantasai: That creates a modified containing block.
   fantasai: by default, you do as in 2.1
   fantasai: If you specify center, then you'll shrink-wrap.
   dbaron: 2.1 isn't quite that simple. Function of whether width and height
           are specified
   TabAtkins: If neither is auto, then we do these things.
   TabAtkins: was confusing to write!
   TabAtkins: If you have explicit margins and left and right props, then
              when calculating auto width, shrink to fit.
   dbaron: Also, when no auto width, also align.
   Rossen: change of behavior?
   fantasai: No, compatible with 2.1
   TabAtkins: stretch is default. Absposes behave as in 2.1
   TabAtkins: Possible that there are some deep details that we missed,
              so needs review at some point.

   fantasai: Get true alignment in grid and flexbox, but safe alignment
             in doc-centric layout, i.e. tables and blocks.
   fantasai: Can't make them all safe, because flexbox has true.
   TabAtkins: Could define whatever for blocks
   Rossen: Should keep doc-centric ones safe and app-centric true.
   fantasai describes property index

   TabAtkins: Please someone look at legacy left/right/center, is there a
              better way to do it?
   fantasai: Want to express that we're inheriting alignment.
   fantasai Right now only with left/right/center, but if it's useful,
            can allow 'legacy' with start/end as well
   fantasai: Think about: do we want to allow it for other keywords?
   fantasai describes auto/legacy

Reversing Interrupted Transitions

   <dbaron> http://dbaron.org/css/test/2013/transition-reversing-demo
   dbaron: only tested in gecko
   dbaron: relies on mouseenter/mouseover, but those are even worse than
           a decade ago
   dbaron and TabAtkins discuss JS implementation

   dbaron explains various proposals in testcase
   dbaron: There were other proposals, but I didn't implement
   TabAtkins: Your proposal is better than the current spec, at least.
   dino: Reversing is only when in a transition and you set the value to
         where you came from? If it has ended, run a normal transition?
   dbaron: yes
   SimonSapin: What if enter a transition and go to another one?
   dbaron: No special treatment. Hard to implement sensibly.
   fantasai: if we have transition-in but not -out?
   dbaron: Then will not have transition-out.
   dino: What if a different timing function or duration? should break
   dbaron: Disagree.
   dbaron: in many cases people will want different timing functions,
           because they want that behavior.
   dbaron: With my approach, they'll still get the specified timing function
           for each direction.
   dbaron gives example with timing function on hover state

   dino: People that care about this will want to tweak everything. Can't
         address that without adding props.
   dino: Just make it work for the majority of cases
   fantasai: If timing-in was 4s and -out was linear 4s…
   dbaron: My proposal looks only at value, not timing.
   dbaron: Sometimes 50 % through value space in 12 % of the time
   dbaron: I say 50 % in 50 %
   dino: If linear in both directions, 4s one way 2s in the other…
   [not minuting clarifying discussion]
   fantasai: What if the timing function is slow for 15% and then fast?
   dbaron: That's ease-in
   dbaron: If you mouse out at 50%, the time going back is close to the
           time going forward
   dbaron: Time going back was shortened quite a bit
   krit: ease-in is better with the current spec, ease-out is better with
         your proposal
   dino: Depends on when you interrupt it
   rik: goes too fast back when shortening the time
   dbaron: Don't like discontinuity between 99% and 100%
   dino: Some people might want an interrupted transition at 99%, pretend
         it finished.
   dbaron: Mine: it gives 99% of the duration, so almost undetectable.

   dino: Should just pick one, yours is fine. Let's implement it and see.
   dbaron: Has always been like this in Gecko
   krit: Safari just unprefixed transitions

   dino: Concern is that people have content where they instead of transitionEnd
         event assumed that something happened.
   dino: we're effectively changing t-duration on them.
   TabAtkins: Adding a delay between the real end and the …
   dbaron: Probably need some real events for interruption
   dbaron: no transitionend event.
   dino: There's interrupted and there's paused.
   dino: suspended, e.g. if animations are paused on scroll
   dino: duration is possibly longer
   dino: People have requested that if prop is set to same value, then no
   dino: Adopt your proposal.
   cabanier: Apple's spec is better, actually.
   dino: I don't care much. Want to stop hover complaints.
   dino: Safari has no reversing, so need to implement to see.

   cabanier: Don't we already have a demo for side-by-side?
   dino: Need a complete implementation.
   krit: Can also be decided in CR.
   plinss: Do we want to change?
   TabAtkins: Spec behavior is bad.
   krit, cabanier: no, not bad.
   dino: We don't know, because we haven't implemented it.
   dbino: propose dbaron's suggestion. Firefox already shipped, looks good
   RESOLVED: dbaron's proposal for reversing interrupted transitions is accepted.

Meeting adjourned.
Received on Wednesday, 3 July 2013 05:57:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC