Support both object and string as value for style attribute.

[rbiggs]

In both Hyperapp and Superfine the only way to apply an inline style is by providing a object. This is great if you need to create CSS values dynamically from code. But most of the time I'm just applying some simple styles, no need to calculate anything. Supporting both would only require a minor change to how to set the style attribute in updateAttribute:

// line 161:
} else if (name === "style" && style !== 'string') {

Then you could use:

<div style='color:red; padding: 5px;'></div>

or:

<div style={{color: 'red',  padding: '5px'}}></div>

Maybe it's just me, but I feel its easier to type out a string for styles than creating an object inline.

[frenzzy]

We have two PR about it: #675 and #676
You also may use style={{ cssText: 'color:red; padding: 5px;' }}

I thought this feature would be very useful when you want to render svg as jsx - no need to convert manually a lot of style attributes. But later I come up with solution: always convert inline styles into svg attributes using SVGO. For example: <path style="fill:red" /> to <path fill="red" /> etc.

[zaceno]

I second this request. Supporting both strings and objects for the style attribute would be 💯 (And it would be analog to building in classcat support in the class attribute, where class as string-list and object would both work)

Now that hyperapp isn't quite so size focused anymore, it shouldn't be a problem (although the implementation is tiny anyway)

[jorgebucaran]

@rbiggs Let's do it then! 🎉

[rbiggs]

Yay!!! 🎉🌈🍻To be honest, I've been hacking Hyperapp and Pico-ultra-superfine since forever to support this feature.

[infinnie]

#Everybody be hacking his own

[jorgebucaran]

You should be able to use a string or an object to set the style attribute of an element now!

With a string

const viewRed = state => <div style="color:red;">Consider it done!</div>

With an object

const viewRed = state => <div style={{ color: "red" }}>Consider it done!</div>

[jorgebucaran]

I removed this issue from the V2 milestone as I don't think I will be bringing this feature over to V2. I was too eager to resolve this issue and didn't pay it enough attention. It's all my bad, @rbiggs was simply submitting a feature request. 🙇

I don't see how this feature could be seen as superior to current object syntax, so I am not compelled to have this added to V2.