search

Experience-Monks / f1-dom

Create f1 ui with the dom
MIT License
12 stars 4 forks source link

feature request: transforms for translating xPercent, yPercent #4

Closed cheapsteak closed 8 years ago

cheapsteak commented 8 years ago

For responsive/fluid-sized elements it's more intuitive/less work for library users to specify certain states using percentages for translations rather than pixel values

GSAP uses xPercent and yPercent, recommend using the same api to lessen switching cost

mikkoh commented 8 years ago

How do you see this looking from a usage perspective? You pass in strings with % appended to a number? eg. x: '10%'

One thing I'm having a bit of a hard time with is for other platforms the parser would need to know the width and the height of the object in order to apply percentual transforms.

Also what if a person puts mixed values eg in one state it's a percentage in another its a regular value?

If flexibility is required then even for dom it would be good to define a width and height for the object. This could be done by introducing a breaking change to f1-dom where f1-dom is a function that returns an object. This way you could do something like:

require('f1-dom')({
  width: 100,
  height: 100
});

Doing the above would allow for percentual translates with mixed values (percent and non) between states. It would also work in other environments.

cheapsteak commented 8 years ago

Usage would be the same as GSAP

xPercent and yPercent would accept a number, no "%" required because it's already apparent from the property name

The width and height is responsive/fluid. There are instances (especially when using flex-box) where it's much much easier to have the box-model handles layout for us

Perhaps in time f1 could create an abstraction for flexbox like react native did, but until then, it would be great if we wouldn't have to choose between F1 and the box-model

I don't like the idea of imposing substantially more work on developers for current projects for the potential future benefit of someone working on a canvas project. That weight should be borne by the library, the library should make lives easier for us not harder.

Canvas projects are hard mode, every project doesn't need to be on hard mode on the chance that a component might get reused for a canvas project (and a canvas project that decides not to use DOM for UI at that)

cheapsteak commented 8 years ago

resolved by https://github.com/Jam3/f1-gsap