UNPKG

transition-style

Version:

just add water clip-path mask transitions

transition.style

argyleink/transition.css

47 lines (32 loc) • 2.75 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# How to Contribute We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow. ## Contributing to transition.css Thanks for your interest in contributing! Before contributing, please make sure you understand the guidelines provided here. ## Design Guidelines Transitions, like many facets of visual and interaction design, can be highly subjective. Maintaining a consistent library of transitions in an active community can be difficult; these design guidelines are designed to help encourage thoughtful criticism of new transitions that are proposed for transition.css. The transitions in transition.css should follow a few key principles: - **Transitions should be tolerable.** Transitions should be tolerable, seeing them repeatedly should not become too annoying or overbearing. - **Transitions should not interfere with document flow or control/input availability.** In other words, the absence of an transition should never reduce usability of a product: they should be non-critical and seen as “progressive enhancements”. - **Transitions should be helpful.** They should be designed to move users through moments of interest, ease natural reading order, or to communicate relationships between spaces. - **Transitions should feel familial.** Avoid introducing transitions that feel out-of-place compared to the existing set. - **Transitions should feel natural.** Transitions should reflect, as much as is reasonable, motion that occurs in natural physics. Avoid extreme timing functions, and model transitions on real-world events. - **Transitions shouldn't run on devices without the power to do so.** If a device is contrained in battery, memory, GPU, etc, then it's a good idea to avoid transitions. ## Contributor License Agreement Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to <https://cla.developers.google.com/> to see your current agreements on file or to sign a new one. You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again. ## Code reviews All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more information on using pull requests. ## Community Guidelines This project follows [Google's Open Source Community Guidelines](https://opensource.google/conduct/).