StyleAttr.cssFloat should use the float css property name about karax

[ajusa]

Hm, with

include karax / prelude
import karax/vstyles

proc createDom(): VNode =
    result = buildHtml(tdiv(style = style((StyleAttr.cssFloat, kstring"right")))):
        text "Hello World!"

setRenderer createDom

I get

<div id="ROOT" style="float: right;">Hello World!</div>

on the current master branch of Karax.
However, if you are using it just to generate HTML, then this might be a bug as https://www.w3schools.com/jsref/prop_style_cssfloat.asp says cssFloat is only used for the JS property to set it, despite the actual name being float. So when using the Karax DSL directly on the non JS backend, I get

<div style="css-float: right; ">Hello World!</div>

which seems to match your issue. Not sure what the best fix here is. An easy one is just a hack to check and see which backend is being used, and translate accordingly. My guess is that this is the only CSS property with this issue, I glanced through the other ones that Karax provides and those seemed fine.

Suggested workaround:

proc createDom(): VNode =
    result = buildHtml(tdiv(style = "float: right;".toCSS)):
        text "Hello World!"

It is possible to directly set the style using Karax.

[jfilby]

Yes, I'm using Karax to generate HTML in this case.

[timotheecour]

@Araq is there any situation where StyleAttr is preferable to toCss (introduced in #158) ? toCss is easier to use IMO because it's easier to go back and forth between css vs karax (and doesn't have this issue);

if there's no such situation, should we migrate the code in karax to use toCss and promote it in docs?

[Araq]

Can't remember, but what I do remember: The style handling code is most performance critical and can easily dominate the performance profile in a real-world app, not just in benchmarks. You probaly need to make toCss a compiletime operation.

[timotheecour]

You probaly need to make toCss a compiletime operation.

then maybe it's time to merge nim-lang/Nim#15528 (const now works with ref types) ? There are so many use cases for it (including table at CT, jsonNode at CT etc);

(so that proc toCss*(a: static string): VStyle overload can be defined)

(note that addressable const should not use const but let a {.rom.} = [1,2,3], so it doesn't clash with nim-lang/RFCs#257 in any way; see timotheecour/Nim#553 for some pre-RFC)