Setting opacity to 0

[mrjjwright]

I set opacity to 0 as follows:

h( "div", { class: "", style: { width: 15, height: 15, opacity: 0 }, oninsert: function(el) { checkEl = el; } }, "✔" )

Picodom is not outputting an opacity css style prop on the element. If I set it to 0.1 or higher it does.

[jorgebucaran]

@mrjjwright Interesting! I think this might be a bug. I'll keep you posted. 💪

[mrjjwright]

Thanks, also it appears that strings like “0” work, which might be a clue.

…

On Jul 22, 2017, at 9:48 PM, Jorge Bucaran ***@***.***> wrote: @mrjjwright <https://github.com/mrjjwright> Interesting! I think this might be a bug. I'll keep you posted on this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQ9zKefLZao5iArQZHz-v_TYRqal3Aks5sQsKMgaJpZM4OgSVU>.

[OneMorePound]

I think this line is why there is a bug (value['opacity'] is 0, which is a false value) . And change this line to element.style[i] = String(value[i]) || ""; can fix this.

[jorgebucaran]

Thanks @yepbug. Yes, that should do it.

@mrjjwright Just curious. Why were you using a number instead of a string?

[acstll]

Here's some interesting discussion: WICG/webcomponents#519, WICG/webcomponents#519 (comment)

I think doing String(value[i]) || "" might not be the best answer, because other values like false or null would be stringified as well and you don't want opacity = "null". Maybe something like testing against value[i] not being null or undefined?:

element.style[i] = value[i] != null ? value[i] || ""

The most important thing would be to settle on the API first, should attributes accept only strings? how should other types be handled? And make it clear on the documentation.

[jorgebucaran]

@acstll Why would you use a number instead of a string again?

[acstll]

@acstll Why would you use a number instead of a string again?

I can imagine getting the value out of a computation, for example, so you just use that. You do something like { opacity: result }; it's just easier. One can always do { opacity: String(result) } I guess.

I'm in favor of only accepting strings as attribute values, so this here wouldn't be a bug. And I'm just giving my opinion here I'm not even using picodom myself :-)

[mindplay-dk]

IMO, disallowing number doesn't make sense - this is Javascript, and people will use numbers regardless of any specification or documentation. What would you do, throw an Error? That would likely be surprising to JS developers who naturally expect scripts to handle different types dynamically - it would just be pedantic.

IMO, the challenges here are minimal - handling numbers poses no real difficulty, so there's no practical reason to create problems or surprises by disallowing numbers: principle of least astonishment.

[jorgebucaran]

Sounds good, but we could argue that picodom shouldn't even bother with inline styles (allow setting style attribute only, which is currently impossible).

Compared to CSS, inline styles are slow. Or one could use a CSS-in-JS solution.

What do you think?

[mindplay-dk]

IMO, support for inline styles is pretty universal across JSX implementations - it would suck not to have this, and (regardless of micro performance concerns) it already provides a basic CSS-in-JS solution, since you can simply create objects/modules with reusable CSS properties.

If someone has extreme performance requirements, they can either use regular CSS or a CSS-in-JS solution, there are plenty of options, but basic object-to-style property binding is pretty universal and likely a reasonably natural expectation for most people.

[acstll]

I'm gonna PR this so we can discuss over a possible solution and not about things sucking or not. ✌️

[mindplay-dk]

Good call 😊

[mindplay-dk]

The PR was merged, so we can close this?