- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Jun 2014 19:36:03 -0400
- 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