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

[CSSWG] Minutes Seoul F2F 2014-05-19 Part II: Transitions and Animations, calc()

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 8 Jun 2014 19:36:03 -0400
Message-ID: <CADhPm3tzygRQhEBeaoMV8J0+mfJu=j4wO_wNDi6FBJO1QDs+6w@mail.gmail.com>
To: www-style@w3.org
Transitions and Animations
--------------------------

  - For transitions, dbaron stated that there was only one major issue
    to be addressed before last call: how to handle when a transition
    starts/stops
      - This is a major issue, however, and will require a dedication of time.
      - Current hope is to be able to address it in June
  - For animations, dbaron stated that there was a lack of editorial
       resources to allow the spec to progress. Several people were
       suggested as being worth approaching for editorial help.
  - Shane discussed his work creating a cohesive approach to
       transitions, animations, and web animations which he intends
       to be the foundation of transitions/animations 4.
  - RESOLVED: Migrate Shane's document
       (http://rawgit.com/shans/98cb810920ac43876020/raw/b77db7529411066c9f3cdd36a52d0b98553525f9/Overview.html)
       into the dev pages and the SotD section should say that it's
       intended to be incorporated into Transitions and Animations 4

calc()
------

  - The issue of whitespace in calc() was addressed.
  - The group agreed that there was no way to completely eliminate
       whitespace requirements, instead only being able to limit the
       instances of required whitespace.  This lead the conversation
       toward what was easier for authors - getting close to the
       ideal of no whitespace or sticking with existing easy to
       remember, though non-ideal, whitespace rules.
  - RESOLVED: No change to calc() whitespace rules

====FULL MINUTES BELOW======

Agenda:  http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

Transitions and Animations
--------------------------

  glazou: So transitions/animations and OM issues
  dbaron: Should we start with transitions? The issues are pretty
          different.
  dbaron: So.
  dbaron: When we met in, I think a year ago.
  dbaron: We had agreed to... We had an issue with a bunch of
          different ways for how transitions started...
  dbaron: No one liked their own except Safari, who couldn't explain
          theirs, so we had no proposals on the table.
  dbaron: I came up with one that people were okay with that we put
          in the spec, but at the time we had no implementations
  dbaron: I think in Paris Shane said Google had implemented it.
  shans: Some of it.
  dbaron: When I tried to implement in Gecko, I found a piece that
          didn't work, which Shane also ran into.
  dbaron: I am hoping I will have some time in the next few weeks to
          think about a fix.
  dbaron: Basically the spec is based on having a coherent way to
          say when transitions start and how to start them.

  shans: This is the iteration between transitions and animations?
  dbaron: The edits I made in the fall was transitions/animations
          and transitions on same properties depending on ancestors
          and descendant.
  dbaron: There's a bunch of hard cases whose behavior changes based
          on the model.
  dbaron: There was a lot of disagreement on those cases.
  dbaron: We decided that we like the behavior from the model spec.
  dbaron: Currently it breaks interrupting of running transitions
          and that's what needs a fix.
  dbaron: Other than that I think transitions is ready for LC.
          That's pretty significant, though.
  dbaron: I think we shouldn't move to LC, but someone or I needs
          time to figure this out
  dbaron: I don't think it's that hard if I had a solid chunk of 3
          days, but I'm not expecting that until mid-June.

  clilley: I have a question. You said the model is wrong, but we've
           before gone forward with an imperfect model. How much are
           we paining ourselves into a corner?
  dbaron: Depends on if you care about implementations not conforming
          to spec.
  clilley: Yeah, that is fairly bad.
  dbaron: It doesn't start certain transitions that need to start.
  dbaron: In particular when you have a transition that happens when
          you move the mouse over and when you move the mouse away,
          it lets the transition move out.

  dbaron: I don't think there's much to discuss unless someone has
          thoughts.
  shans: I don't know how to fix it in the spec.
  dbaron: I've be curious to know how you fixed it in your
          implementation. I wrote a series of patches, started the
          tests, and realized that transitions that interrupt don't
          work.
  dbaron: Now my patch series has the same bug as the spec.
  clilley: That's fine. You've proved the spec is wrong, but if
           people have implemented it there must be something that's
           working.
  dbaron: There's a pile of edge cases where implementations do
          different things, except we've broken a case where they
          were inter-operable.

  fantasai: You said you'd have time in June?
  dbaron: I hope so.
  fantasai: So maybe we aim for LC at end of June?
  dbaron: That might be tight. shans and I can talk.

  dbaron: I think I should move on to animations.
  dbaron: That has a lack of editorial resources. I've mostly kept
          up with transitions edits, but not animations.
  dbaron: I added a list of pending resolutions that need edits so
          people know what's wrong.
  dbaron: I was hoping sylvaing could help with editing.
  <krit> I think he is looking into it already

  clilley: Brian Birtles understands these issues. He's got a model
           in his head, can he be dragged into editing?
  shans: I'm not sure if he has the integration part in his head.
        He's been deferring to myself and TabAtkins
  shans: We have a model of web integration almost ready to be
        looked at. Maybe I can get that work to the list.
  shans: There's a question about animations integration. Maybe we
         can do that now?

  [brief pause as the white board arrives]

  dbaron: So the state of animations is stuck on editing resources.
  dbaron: I don't know how much exposure he has to CSS concepts.
  clilley: Given that he doesn't understand the concepts and his
           spec is supposed to be wonderfully useful
  shans: There's a lot of us working on that spec and between us we
        have a good grasp,
  shans: You don't have to model every CSS concept in web
         animations to make it work. There's a shadowy topic of
         what does CSS do to start/stop animations.

  <shans> http://rawgit.com/shans/98cb810920ac43876020/raw/b77db7529411066c9f3cdd36a52d0b98553525f9/Overview.html
  shans: At the moment we have transitions and animations, we have
         web animations and we've just started a 3rd piece.
  shans: That talks about how to take the concepts from CSS to web
        animations.
  shans: We were looking at this while discussing web animations
         and trying to decide if this 3rd piece makes sense or if
         it makes sense to re-write.
  clilley: And to help us to discuss: what were your findings?
  shans: I think it's useful, but I don't know what level.
  dbaron: I feel we should get the current set out with the model
          they have because we have implementations and
          interoperability.
  clilley: Weren't you arguing the opposite about it not working?
  dbaron: That's a small set of issues.
  clilley: That's not what I heard.
  hober: I think that's not what I said. We have a lot of edge
         cases, but I agree with dbaron that we should get out and
         think about the other issues in the future.

  clilley: This goes back to my last comment, though.
  dbaron: I think there's a different time scale of work.
  dbaron: Transitions issues can be solved in a week, but I don't
          think someone can re-write in a week to match web
          animations
  shans: I agree with that. It would be a lot of work to do the
          rewrite and a lot more to get things correct.
  <birtles> fwiw dbaron is right, I don't know all the CSS-specifics
            (and I agree we should get out the current level spec
            without confusing it with web animations)

  clilley: I take the point about verifications, but it doesn't
           sound like they're using any specific model
  dbaron: But we were talking about the model about starting
          transitions before, but now we're talking about the whole
          model, which is a lot bigger.
  shans: It's not as big as it sounds. Web animations model talks
         about how to do interpreted values and put them back into
         CSS. The start/stop remains unchanged.
  shans: Unfortunately, that's the stuff we have trouble with.
  dbaron: I'm fine with someone doing the other in parallel, but I
          don't think we should block advancement.

  clilley: You said a week of work, you mean one not doing anything
           else. Is that likely?
  dbaron: I'll see. I'm hoping 2nd half of June
  clilley: I'm trying to not have a thing where the skies have to
           open to make this work.
  dbaron: I don't think it's that complicated. I also think it's
          really a day, which is why I'm saying a week
  clilley: So we're almost ready for LC?
  dbaron: For transitions, yes.

  dbaron: Was there stuff you wanted to discuss about this draft?
  shans: Not specifically. I think it's worth looking at some
        point, but not high priority.
  shans: I have some changes to integrate, but than I'll send an e-
         mail. I wanted to clarify what we should be doing and I
         think that's clear.
  shans: This should be part of Animations 4. I think this draft
         will never be a spec. It'll be a reference until we're
         ready to merge.
  shans: Than we'll publish transitions/animations 4.
  dbaron: Sounds fine to me.

  Rossen: Is this something you're proposing bringing into CSS?
  Rossen: I see this is something you posted outside of W3C.
  Rossen: I don't remember this...are you going to bring this
          officially?
  shans: That's the question. It's not published at all, it's just
         available for sharing

  clilley: So web animations is going onward. I'd imagine this will
           be integrated into it.
  shans: My proposal is to keep this as an unofficial reference
        until transitions/animations 3 is ready.
  shans: Than roll this into transitions/animations level 4.
  shans: So we won't have another spec lying around.

  glazou: Your doc is a W3C...maybe we should move this to the dev
          pages?
  shans: Absolutely.
  glazou: It's only an unofficial ED.
  glazou: We decided a while ago to move stuff to dev only if the WG
          agrees.
  clilley: We've lots of times had two levels going.
  glazou: This is up to the WG. Any objections?

  shans: To be clear, we're saying take my doc and put it on the dev
         pages and than start to bring it into animations 4 later?
  dbaron: If we want to start to edit now or later is open.
  hober: The question is just to bring it across.

  plh: Does this need to be charter?
  Rossen: If it's title is transitions/animations 4, no.
  plh: I just want to make sure it's in the right place with the
       charter.
  clilley: Thanks, by the way for the AC's that have commented on charter.

  clilley: So is this transitions/animations 4?
  shans: Eventually.
  clilley: So do we want to call it that now so we can put it in the charter?
  glazou: If we want to add to the charter, some ACs have already
          voted, so what would happen to the charter? re-vote?
  plh: We have to get the approval to do that.
  clilley: We have comments from an AC asking for edits, so I've got
           a copy with edits already.
  glazou: From an AC prospective, some people could be bothered
          about adding a new doc.
  dbaron: If an AC suggests we add that doc, though, we're okay.
  glazou: Okay.
  clilley: I'm not editing the AC copy.

  clilley: So do we have a resolution on that?
  glazou: So move that document to dev pages?
  dbaron: I think ar minimum that status should say that the intent
          is to merge.
  hober: I'm not comfortable with the title change.
  dbaron: I think this shouldn't get the name, yes.
  clilley: It just means I need to put this title in the doc.
  Rossen: If we need it to be unofficial...
  plh: So if it'll be integrated at the end, we don't need to change
       charter.
  clilley: Okay.

  RESOLVED: Migrate shans document
  (http://rawgit.com/shans/98cb810920ac43876020/raw/b77db7529411066c9f3cdd36a52d0b98553525f9/Overview.html)
  into the dev pages and the SotD section should say that it's
  intended to be incorporated into Transitions and Animations 4

  glazou: I suggest a break, 10 or 15 min
  shans: Did dbaron have anything further to discuss?
  dbaron: [shake head]

  [break = 15 min]

glazou: Let's start.
glazou: Should we continue animations?
dbaron: Did we have other things to discuss?
glazou: There one about animations OM issues?
plinss: Also, the cascading behavior?
TabAtkins: That's the how do things start we were discussing.
dbaron: I don't know who added those items?
plinss: What are the OM issues?

[silence]

TabAtkins: Zakim excused himself...is he needed?
glazou: No
glazou: Let's move on to calc()
TabAtkins: Yes.
TabAtkins: [heads to the white board]

<sgalineau> css-animations OM issues were those raised by Daniel.
* sgalineau happy to join in on Tue or Wed AM if there is time. Or later.

calc()
------

  TabAtkins: It's the plus/minus thing
  TabAtkins: Right now, calc() requires spaces around + and - to
             avoid ambiguities.
  TabAtkins: There's a proposal to allow us to omit these.

  TabAtkins: Does anyone need a review, or are we just doing
             whatever TabAtkins wants?
  dbaron: I'd like to hear it.
  hober: With examples.
  TabAtkins: For example, right now I need to write 1 + 2 it
             tokenizes as a number.
  TabAtkins: One change is that if you get the right combination of
             tokens, if you run into a + or - it assumes that it's
             negative/positive.
  clilley: Can I do 1 + -2?
  TabAtkins: Yes.
  TabAtkins: This is the less complex.

  fantasai: Does that first one mean if I write 1/**/2 it would work?
  TabAtkins: No. In this new approach it remembers if numbers are
             positive or negative.
  TabAtkins: It looks at the representation to see if there was a
             plus sign.

  plinss: To clarify. In the case with a negative, you're converting
          to 1 - 2 to 1 - +2?
  TabAtkins: Yes.
  plinss: The thing is you can always tell it's addition if it's
          number number, but at some point we need to know if we're
          adding a positive or a negative
  TabAtkins: This is us fighting the process to get it to do what we
             want.

  TabAtkins: The complex part is about units
  TabAtkins: + isn't relevant because as soon as there's a unit it's
             easy.
  TabAtkins: The hard part is negatives.
  TabAtkins: 1px-2em looks like one big dimension token.
  TabAtkins: The current proposal that I'm okay with is we change
             the syntax parsing of dimensions.
  TabAtkins: The unit is slightly more restrictive so you can't have
             a dash after the unit.
  TabAtkins: So that (above example) would become 1px and -2em.

  dbaron: So you're adding a 2-character lookahead to the scanner?
  TabAtkins: Whenever we...It's only one...no, it is two characters.
  TabAtkins: It's already got a 3-char lookahead.

  plinss: So you can have dashes in units as long as it isn't
          followed by digits?
  TabAtkins: Yes. prefixes are still valid in dimensions.
  clilley: Do we have syntax for prefixes and does it allow digits?
  TabAtkins: Right now it's an ident.
  clilley: For a vendor prefix?
  TabAtkins: Yes.
  dbaron: If a vendor prefix starts with a number you're in trouble.
  <liam> [ calc(3px - border-width) ]
  clilley: So to use this as units, you have to put a restriction on
           vendor prefixes.
  TabAtkins: It would never work.
  dbaron: You want your vendor prefix as 2px, it would be a dimension
          anywhere.
  clilley: I'm looking for consistent.
  TabAtkins: It is. Vendor prefixes are in ascii vendor range.

  hober: Are there any cases left that require whitespace?
  glazou: Do we need a digit after a dash in idents?
  TabAtkins: Yes.
  TabAtkins: Translate -3d I think
  <dbaron> transform-style: preserve-3d means we need to keep
           allowing it in idents
  zcorpan: There's one place with whitespace.
  TabAtkins: Yes. If you're trying to subtract a function.
  TabAtkins: If I say 2px - attr(foo). Without white space it would
             be a dimension with stuff.
  TabAtkins: The thought it this is okay because people are familiar
             with white space and dashes in ident names.
  hober: I don't think so.
  fantasai: Especially in areas where people don't use spaces
            between words, I don't think that logic works.

  hober: The model in CSS is that I can use calc() to produce
         values and I can use it anywhere, without having to
         change any of its surroundings.

  glazou: If preserve-3d is the only case requiring whitespace, why
          don't we change that?
  fantasai: We'll have same problem with min-content. We can't
            change all keywords.
  glazou: I'm saying to forbid digit after dash.
  TabAtkins: If we only did numbers, it would only help us with
             number and number.
  plinss: You only need the space after the dash?
  TabAtkins: There are no trailing dashes.
  plinss: In idents?
  TabAtkins: We can make that a no...
  TabAtkins: calc() can examine and say it's a negative. This is
             less awful.

  TabAtkins: Opinions?
  fantasai: I'm against this because I think it'll make functions
            and keywords confusing since they won't realize when you
            swap you need spaces.
  TabAtkins: I agree, but I see why we'd want to optimize for the
             common case.
  dbaron: There's the common case and than there's editing and
          modifying.
  hober: If I do a search and replace, it's going to break half the
         places.
  plinss: Only if you're replacing inside a calc().

  clilley: So it's either you have to use spaces all the time or you
           can get rid of them sometimes, but you have to remember
           when.
  clilley: That's what you're against?
  fantasai: Yes. I'm all for optimizing the common cases, but as you
            transition to more complicated cases, don't want to trip
            people up.
  dbaron: Or you get rid of dashes in units and removing the
          possibility of vendor prefixed units.
  TabAtkins: Yes.
  hober: The only unit I know is __qem
  hober: It's only used in the WebKit UA stylesheet, so it doesn't
         trip over this case.
  TabAtkins: Doing so would mean we can't later allow user spec
             dimensions because they start with --
  TabAtkins: Or they can start with a dash, but not contain them
             inside.

  zcorpan: If we change as dimensions, it wouldn't solve the keyword
           issue.
  TabAtkins: It wouldn't solve several cases
  dbaron: But you can do it the way you describe where the -attr
          function in calc() is a - only.
  TabAtkins: It would be problematic, still, with vendor prefix.
  TabAtkins: Like we couldn't do -webkit-attr() unless we add
             special cases.
  TabAtkins: And keyword-keyword
  zcorpan: On the flip side if we want to require spaces, the
           current spec doesn't do that.
  dbaron: Currently we require spaces around + and -, but not the
          others because we didn't need to.
  dbaron: So there's a grouping that makes sense with multiplication
          and division.
  dbaron: Multiplication/division bind tighter than addition/
          subtraction
  fantasai: You can certainly put spaces everywhere.
  <dbaron> calc(auto-min-content)

  zcorpan: So the search and replace argument, does that apply?
  TabAtkins: Well, if you're doing * to / you'll break way more.
  Like comments.
  zcorpan: I can see that. On the other hand if you're first used to
           multiplication and than you move to addition and you need
           to add spaces.
  TabAtkins: I agree it's confusing.
  TabAtkins: There's author feedback saying the spaces are confusing.

  hober: So we have a compatibility constraint and there's existing
         content. To address author confusion we can't force spaces
         everywhere because compat.
  hober: The other way is to make the whitespace always optional.
  TabAtkins: That's literally impossible, though.
  hober: So if neither extreme is possible, which do we move toward?
         It seems optional as much as possible is better.
  fantasai: Since we have to pick the middle, we can decide our goal
            is get as close as possible to one, or to pick a logical
            line that makes it easy to understand.
  fantasai: I think that we're at a logical place.
  fantasai: It's not as close to our ideal as possible, but we can't
            get all the way there anyway, and the rule we have is easier
            to understand and remember than the one proposed.
  glazou: I think the discussion is to make it so authors can use it.
  hober: I agree, but I think your point is different.
  TabAtkins: fantasai is saying that current spec is clear and easy
             to understand but the proposal requires knowing and
             remembering a lot more which is worse.
  TabAtkins: You have to understand why something does/doesn't make
             sense.
  fantasai: If we keep it where it is, you don't need to understand
            parsing, you just have to remember + and - need space.
  TabAtkins: The rule becomes you need space around keywords which I
             think is reasonable.
  fantasai: That is, but it's a more complex thing to understand and
            a more complex line.
  fantasai: We can try to get closer to where authors want, but we
            can't actually get there and the solution would be worse.
  TabAtkins: I can agree with both.

  zcorpan: I don't understand why we can't always need spaces.
  TabAtkins: Too much existing content already don't use the spaces.
  TabAtkins: There are things out there in the world that we can't
             get rid of.
  TabAtkins: I don't know how to resolve this because I can't decide.
             Someone else needs to decide this.

  glazou: I'm ready for a straw poll.
  TabAtkins: Options are no change or this
  hober: So going back to authors needs, I'd like the poll to be
         what authors need to remember.
  TabAtkins: Option 1) Space around - and + all the time
  TabAtkins: Option 2) Space around - when using functions and keywords.

  glazou: So before the poll, what is the current approach?
  TabAtkins: Option 1
  glazou: So is there a third option before we do the poll?

  dbaron: In 2 you're saying that when you're using functions in
          keywords, there has to be a space around just the - sign
          and are you saying the space has to be on the side of the
          minus sign?
  TabAtkins: Yes.

  glazou: Let's do the poll.
  clilley: 1
  Rossen: i
  dbaron: 1
  glazou: 1
  glenn: abs
  jet: abs
  koji: 1
  <krit> abstain
  koji : abs
  fantasai: 1
  zcorpan: 2
  astearns: 1
  andre: abs
  <liam> 1 because any option that needs a full whiteboard to
         explain it must be bad :-)
  addneilson: 1
  bruno: 1
  dwim: 1
  TabAtkins: abs
  hober: 2
  plh: abs
  shans: abs
  shinyu: abs
  dauwhe: abs
  plinss: abs

  TabAtkins: So it seems clear for 1.
  hober: I can live with that.
  glazou: zcorpan can you live with 1?
  zcorpan: I can live with 1. I think SimonSapin said 2 on the
           mailing list.
  <dbaron> I don't feel that strongly either; I'd be ok with 2.

  hober: The quick case for 2 is that it would be easy for the web
         inspector to highlight the odd cases with this problem.
  hober: It's unusual to encounter this.
  TabAtkins: For now. When we allow keywords it'll be more common.
  hober: You add more than you run into this problem.
  glazou: I was looking for something more usable and be able to do
          things as we say it.
  hober: 2 is as close as possible.
  glazou: But 2 makes it weird.

  RESOLVED: No change to calc() whitespace rules
Received on Sunday, 8 June 2014 23:36:31 UTC

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