Since android's `Row` modifier `horizontalScroll()...

# kobweb

[ursus]

Since android's Row modifier horizontalScroll() is not available, how do I make a container of fixed width have its children horizontall scrollable?

[S.]

with overflow https://developer.mozilla.org/en-US/docs/Web/CSS/overflow

[S.]

Modifier.overflow(overflowX = Overflow.Scroll, overflowY = Overflow.Hidden)

[ursus]

are there any docs or do I have to figure out css way of doing a thing and then hoping kobweb has it mirrored?

[S.]

well, it is css so there's no way around it. I would refer to the mdn docs for css or js.
kobweb already supports most properties as modifiers, if you find one is missing just mention it in this channel and it will be added. but I think at this point there are only very niche ones left.

[S.]

generally what you want to do for css styling (or js browser functionality) is to search the internet how you would do it with plain css/html/js and try to recreate it in kobweb. often you'll find code snippets which you can paste into https://opletter.github.io/css2kobweb/ to quickly turn css into kobweb code

I sent this to another thread but have a look at the css2kobweb site

[ursus]

okay so I should not expect verticalScroll() ever

[ursus]

.. about the translator.. trouble is I dont know css 😀 but thanks

[S.]

no, it's definitely jetpack compose inspired on other fronts like Row and Column but the modifiers are a mapping of css. otherwise it would be too confusing. you can have a look at the browser devtools (right click -> inspect) where you can edit css live on the page, this also helps a lot. but then you would again have to translate verticalScroll to overflow

[ursus]

yea presence of Row and Column kinda confused my expectations

[S.]

knowing css will come with some time. it's not actually that horrible and the good thing is there are literally thousands of examples on the web and chatgpt etc understand it quite well too

[S.]

there is also SimpleGrid . the css grid layout is quite powerful, this widget provides a very simple version of it without having to mess with grid modifiers yourself

[ursus]

is that a kobweb thing?

[S.]

SimpleGrid is, yeah

[ursus]

okay so no docs, just look around kobweb sources, gotcha

[S.]

there are kobweb docs but for css it's only an overview of how it works https://kobweb.varabyte.com/docs/concepts/presentation/learning-css
so for css docs, like I said mdn

[ursus]

btw how do you keep your colors? in some sort of statically accessed structure? Or something closer tob MaterialTheme.colors.foo shape? (composition locals)

[S.]

object Theme {
    val primary = Color.rgb(2,2,2)
    val secondary = Color.rgb(1,1,1)
...
}

data class SitePalette(
    val primary: Color,
    val primaryVariant: Color,
    val secondary: Color,
    val surface: Color,
    val background: Color,
    val error: Color,
    val shadow: Color,
)

object SitePalettes {
    val light = SitePalette(
        primary = Theme.primary,
        primaryVariant = Theme.secondary,
        secondary = Theme.secondary,
        surface = Theme.white,
        background = Theme.white,
        error = Theme.error,
        shadow = Theme.black,
    )
    val dark = SitePalette(
        primary = Theme.primary,
        primaryVariant = Theme.secondary,
        secondary = Theme.secondary,
        surface = Theme.darkSurface,
        background = Theme.black,
        error = Theme.error,
        shadow = Theme.white,
    )
}

fun ColorMode.toSitePalette() = when (this) {
    ColorMode.LIGHT -> SitePalettes.light
    ColorMode.DARK -> SitePalettes.dark
}

[ursus]

I see, thanks!

[S.]

CssStyle also exposes a colormode property from which you can then get the according palette. as soon as you depend on colormode or things like :hover you should refactor your modifier chain into a css style (https://kobweb.varabyte.com/docs/concepts/presentation/silk#cssstyle) ( or generally to reuse it in other places)
colormode.toPalette() gives you kobweb/silks color theme and colorMode.toSitePalette() the one from above

[S.]

silk colors you can alter like this

@InitSilk
fun initTheme(ctx: InitSilkContext) {
    ctx.theme.palettes.apply {
        light.apply {
            focusOutline = Theme.primary
            background = Theme.white
            color = Theme.black
            link.apply {
                default = Theme.primary
                visited = Theme.secondary
            }

(https://kobweb.varabyte.com/docs/concepts/presentation/silk#initsilk-methods)

[ursus]

yea I think I'll try to provide my own accessor, place the composition local all the way at the top, so I dont need to think about color mode when deep inside

[S.]

typically you want to depend on colormode though if you have two versions for dark and light

[ursus]

Yea i mean I'll read ColorMode all the way at the top, and provide a light or dark color scheme as composition local, like in android

and then just access ColorPallette.primary etc

[ursus]

or is that a bad idea?

[S.]

I'm not sure it makes too much sense tbh. colormode is available anywhere with ColorMode.current anyway. and you need to observe it for your own composition local when you want to allow using browser preferences, which could change anytime

[ursus]

the idea is just to skip the ColorMode literal at callsite, bit cleaner, thats all

[S.]

and not sure if this works well with css styles either,they aren't @Composable code

[S.]

obviously do whatever works for you, it shouldn't be an issue. but in practice you rarely need the colormode or site palette outside of css styles

[ursus]

what do you mean? you access properties that dont change based on color mode differently than those that do?

[S.]

when you know it will always have a static color you can directly use Theme.primary in inline modifiers. for more complex styles that change with colorMode or breakpoints it's better to use CssStyle which uses css media queries that are more performant than observing those in js code

[David Herman]

@ursus Docs for widgets are planned soon, but right now the community is the best way to find these things out. We couldn't prioritize it earlier because we wanted to nail down some basics before we wrote them (so we wouldn't hang to rewrite everything a second time later). Sorry for the inconvenience!