Open Bug 774655 Opened 10 years ago Updated 6 years ago

add an API for starting of transitions

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: dbaron, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

We should add an API to allow authors to explicitly start transitions from JavaScript (probably even without messing with the transition properties).  This will substantially improve performance from the flushing-based hacks that authors have to use now to do this.

See http://lists.w3.org/Archives/Public/www-style/2011Mar/0729.html
(though we might want more parameters to the function)
Keywords: perf
Apologies if I don't have the whole story here or this is a naive question, but wouldn't it be nicer to fix the issue of uncomputed style changes affecting transitions/animations? I don't see why there should be an API for this when there could just be intuitive default behaviour. Especially in the situations where our current behaviour differs with other browsers (or is this perfectly consistent across all browsers?)
Because that would require us to disable optimizations that are critical for the performance of the Web.  Transitions are triggered by changes to computed style; batching up computed style changes until needed is critical for performance.
(In reply to David Baron [:dbaron] (needinfo? me) from comment #2)
> Because that would require us to disable optimizations that are critical for
> the performance of the Web.  Transitions are triggered by changes to
> computed style; batching up computed style changes until needed is critical
> for performance.

Right, but I don't see why they're mutually exclusive? On the simplest level, you could flush style changes before any change to a transitioning property; alternatively, you could batch style changes that transition and ones that don't, and flush when switching between the two?

It just seems if you're changing a transitioning property, you intend it to transition immediately, and the current behaviour is leaking implementation details that a developer ought not to have to be aware of.
I don't understand what you're saying -- but anyway, could you move this discussion elsewhere?
You need to log in before you can comment on or make changes to this bug.