vdux / virtex-element

2 stars 1 forks source link

Simpler style sugar #2

Closed queckezz closed 8 years ago

queckezz commented 8 years ago

toStyle is huge and way to opinionated. As a base element function, something simpler should do. A user can always add autoprefixing on top of it with something like inline-style-prefixer

This pull request removes to-style dependency, adds just basic stringifying and converts camel cased properties to dashed onces.

If possible maybe even move it to @micro-js or we could open a new organization with vdux/dom/front-end related stuff.

ashaffer commented 8 years ago

Yep, i've been meaning to get rid of to-style once I realized that it was practically doubling the size of the bundle lol. Ya this looks good, i'll merge this, but ya making a micro-js version of this, and the classnames thing (or maybe just using classnames, since it's pretty well done and tiny already) are probably good ideas.

I kind of think having it do the autoprefixing would be nice though, but maybe, since adding auto-prefixing after the fact seems kind of annoying, since you'd have to litter it all over the place. Although I guess you could always use your own element.

It's a tough call exactly how much sugar should be built in.

ashaffer commented 8 years ago

Bumped & published.

ashaffer commented 8 years ago

My friend @joshrtay had created a much smaller version of a style object converter when we were using deku over here: css. It does do the autoprefixing, and some unit-related stuff, but it's much smaller than to-style. You have any thoughts on that? I mostly just used to-style because I noticed deku was using in their virtual-element, so I switched to that without really thinking about it.

queckezz commented 8 years ago

Cool that looks actually pretty good. Well it's your call if you want to add autoprefixing. It's just that most of the time, if you need autoprefixing you don't only need basic stuff like transition -> MsTransition but you also need to prefix old flexbox spec, IE flexbox spec etc which this module doesn't do.

Some people also prefer user agent sniffing or using static data from caniuse to identify prefixes. I think it's really opinionated of how you want your styles to be autoprefixed so I would better keep it out of the core.

Maybe add a little note in the readme of viable prefixing options.

queckezz commented 8 years ago

...and the classnames thing (or maybe just using classnames, since it's pretty well done and tiny already)

:thumbsup:

ashaffer commented 8 years ago

Ya, you're right about the autoprefixing. That is too opinionated. Possibly I will add some other stuff like unit conveniences, but autoprefixing will remain out of core.

ashaffer commented 8 years ago

@queckezz I just sent you an invite to the micro-js org, so if you want, you can add that style thing yourself. Just use this template when you make stuff.

queckezz commented 8 years ago

Thanks! So to keep things simple you guys going to stick with es5 for these modules right?

ashaffer commented 8 years ago

@queckezz Ya, we've been using es5 for smaller things. It's not a hard rule, if there's an odd micro-module that is kind of large, and would benefit a lot from es6, it might be ok. But babel's compilation techniques can also introduce non-obvious slowdowns, so it's probably best to avoid it for the most part in micro-js.