Re: Transitions Side Discussion

On Sat, Apr 2, 2011 at 12:38 PM, Andrew Fedoniouk
<andrew.fedoniouk@live.com> wrote:
>>> State of DOM element is a snapshot/set of its attributes and
>>> runtime state flags (:hover, :active) etc. Nothing else, dot.
>>>
>>> Set of CSS properties is a function of DOM element state +
>>> CSS rules.
>>>
>>> Change of state of a DOM element triggers transition.
>>>
>>> But not change of CSS property itself. Otherwise the transitioning
>>> CSS property shall trigger secondary transitions, etc. Quite ill logic
>>> to be honest.
>>
>> Uh, no.  Transitions are triggered by a property's value changing.
>> This is very clear in the spec and implementations.  We get around the
>> "secondary transitions" problem by saying that the animated value of
>> the property doesn't trigger transitions.
>>
>
> I would insist on "Yes".

I don't understand.  Are you disagreeing with my statement?  (If so,
you're wrong.)  Or are you saying that you prefer a different model?


> When UA detects that something has happened on the DOM element it
> triggers recalculation of styles on that element.
>
> In my model "change of state" is a cause of transition.
> In your model "change of state that caused change of css property"
> produces transitions.
>
> So these two are pretty much about the same event but yours is
> more narrowed/limited. The blend() "function" case below is an example
> of things that are not quite possible in your model.
>
> There are a lot more transition effects that cannot be defined
> in terms of single CSS property changes. You cut them off by design.

I agree that many transition effects can't be properly described as a
change in an existing CSS property.  That's why I dedicated an entire
section of my proposal to pointing out that problem, and how to solve
it.


>>> So change of state of a DOM element shall trigger transition
>>> (e.g. change of :hover, :active, some DOM attribute, etc. )
>>
>> Define "state".  You can't use Selectors to do so, at least not if you
>> want to wind up with a consistent and usable definition.
>
> For the purpose of CSS "state of DOM element" can be defined as
> a set of DOM element features changes in which cannot be detected by
> CSS selectors means.
>
> Consider <input type=text> element for example.
>
> It can be in :empty and :not(:empty) states as you can write
> this selector:
>
>  input[type=text]:empty
>
> But you cannot distinguish in CSS input state when it has 2 chars from
> the state when it has 3 chars. So it is said that the input is
> still in non-empty state for the CSS purposes.
>
> I do not see anything wrong with this.

I have a section of my proposal dedicated to explaining what is wrong
with defining "states" (that is, the things that trigger transitions
when they change) via Selectors.


> As of this case:
>
>  1) background:repeat <-> background:no-repeat
>
> that step function of yours is not a solution at all for
> such drastic changes. Consider other cases like transition from
> "no-border-images" to "border-images" case, etc.

I don't understand what you're trying to say here.  All discrete
properties can be easily animated by a step function.


> As of 2) background:url(1) <-> background:url(2)
>
> Reasonable transition here is available only when elements
> gets some :complete state - when image really arrives.
> Change of the property is not enough and really makes no sense.

I don't understand your objection.


> As of 3) replacing content inside the <frame>, etc.
>
> That one is close to #2 - changes of :complete, :incomplete and :busy
> state flags.
>
>> Example 3 can be done with 'content'; otherwise, it's beyond the scope of
>> CSS.
>>
>
> Suddenly it will be in scope if some other module will add, say, :busy state
> flag.

No, my point is that the contents of an iframe are out of scope for
CSS in the outer page.  It's certainly possible for us to define some
kind of "page transitions" that can handle this sort of thing, but it
would be a new concept, not an extension of existing CSS capabilities.


>>> Transition shall define what exactly happens when the element
>>> gets the state *and* what happens when element loses that state.
>>>
>>> Consider these rules:
>>>
>>> button { color: red; }
>>> button:hover { color:blue; transition: color 200ms/100ms
>>> quad-in/quad-out; }
>>> button:checked { color:green; }
>>>
>>> On :hover you will get animated transition from whatever
>>> state it was before (:checked or normal) using quad-in function.
>>> On :hover lost you will also get animated transition (100ms)
>>> using quad-out transition.
>>>
>>> Changes between normal and :checked state are instant - not
>>> animating at all.
>>
>> This is not, in general, a sufficiently powerful model.  It can only
>> be used to define transitions to and from a central state, but not
>> *between* arbitrary states.
>>
>>> All above is not possible to define in current mental
>>> model of CSS Transition module so we'd better change it ASAP.
>>
>> Luckily, this is incorrect.  None of this requires a change in the
>> Transitions model, just in some details.
>>
>
> I've provided simple and practical problem definition above.
> Let me repeat it again then.

Your above example is ambiguous.  What happens when you go from :hover
to :hover:checked?  Does it change color instantly to green?  What if
you then hover out (going from :hover:checked to just :checked)?  What
happens if you set a transition on :checked, and then go from :hover
to :hover:checked?  Which wins, the outgoing transition on :hover or
the incoming transition on :checked?

> Here are three style rules:
>
> button { color: red; }
> button:hover { color:blue; }
> button:checked { color:green; }
>
> :hover on and off has to produce 200ms transitions:
> for :hover 'on' - 'ease-in' function and
> for :hover 'off' - 'ease-out' function.
>
> Changes of :checked alone shall not produce any animations - instant change.
>
> I would like to see how you would do this using "sufficiently powerful
> model" of current
> spec.
>
> This is by the way typical UI behavior of check and radio boxes
> in modern OSes so is a real problem.

button { state-hover: false; }
button:hover { state-hover: true; }
@transition button {
  over: state-hover;
  from: false;
  to: true;
  animation: transition(color) ease-in .2s;
}
@transition button {
  over: state-hover;
  from: true;
  to: false;
  animation: transition(color) ease-out .2s;
}

~TJ

Received on Monday, 4 April 2011 02:00:17 UTC