so you only initialize the select once

As it stands, it will call

.select2()

on that select on every request htmx makes. That might work if

.select2()

is smart enough to not re-initialize, but it could cause issues.

This has probably already been hashed out somewhere but what do people here use for styling htmx apps? Seems to me leveraging the "locality of behavior" philosophy people here would gravitate towards things like Tailwind / UnoCSS (atomic css frameworks) but from a touch of tinkering I just did it feels like the tooling for those css frameworks generally caters to the Js-SPA framework crowd where it feels like it'd be difficult to achieve the same benefits of the tooling in a traditional server rendered app? Curious if people even care, or more importantly if/how you've solved for "Atomic Css" in your stacks?

Just regular ol' PureCSS (https://purecss.io/) or Bootstrap for me, using Scss for customisations. I still have a build step in my projects but it's very minimal. See also #941815579440992337 as a complimentary CSS library to htmx. I've tried Tailwind etc but I'm not keen on that general approach.

Tailwind CSS feels like a logical complement to htmx, as atomic css follows the LoB principal. I use both within a build system (any of Vite, Webpack or Mix will do) and I'm usually building traditional server rendered websites.

Hello all, I just joined but have been tinkering with HTMX for a couple of weeks now. I'm building a proof of concept third-party extension system for a web-app, and i'm using HTMX to allow the extensions to return markup that augments the host app, mainly using oob swaps, but I'd like to be able to scrape data out of the host UI for use in request, a bit like hx-include but allowing values to be obtained from attributes or properties of elements (not just form element values). I've come up with my own custom take on this, but I'm wondering if anyone else has done similar things or knows of an existing declarative solution to this (either in HTMX or elsewhere)?

How does that work exactly tho? I'm coming from Elm specifically elm-ui and one of the benefits is that "styles" have a type of Attribute, so you apply them as values in a list which does a few things. It's spiritually similar to the Attributify thing, only because it's constants in a programming language you get spellchecking and dead code elimination by way of how the program is compiled in Elm. From the little tinkering I did with Tailwind / Atomic, you have to learn the DSL by heart / leverage a bespoke LSP to get autocompletion and if you're using a templating engine for your html or god forbid writing your html in terms of your programming language then that all goes out the window, no? EG: in Elm we don't write

<div> Stuff </div>

we write

Html.div [] [Html.text "Stuff"]

and that compiles to VDom (meh). But the nice thing about it being in Elm is you have the full power of the programming language for extracting things, so making a re-usable Button that's also extensible / override-able in terms of styling is both trivial & (as well as we can code it) correct. With the Atomic approach it seems we get everything from my wishlist except for language integration. But in practice that means there's no semantics for overriding, like

class="p0 p1 p2"

what padding is going to be applied to this element? In elm-ui it'd be p2 because there's "last on wins" semantics in terms of the class list. But in Atomic it's whichever one is last in the compiled stylesheet, which feels wrong to me?

Can't comment on Elm (never used it) but I can say that you very quickly pick up the TW classes and if you need autocompletion then your editor will have a plugin that will do it for you. TW in it's latest iteration is extremely customisable; custom variants is a particularly powerful feature allowing you to vary on, for example, the aria state of a button or a global theme. IMO it works best with a template system that allows you to reuse template partials / components (like Twig). I'm not sure about your overriding semantics tbh, why would have multiple classes like that in the first place? Typically you'd use a variant (e.g. breakpoints)

class="p-0 md:p-2 lg:p-6"

> IMO it works best with a template system Yeh I got that vibe... which may be the only good answer to this :/ > I'm not sure about your overriding semantics tbh

elm
card : Attributes msg -> Config msg -> Element msg
card overrides ({ body } as conf) =
    E.column
        (Border.rounded (UI.length (Size.units 0.5)) -- default styles
            :: Border.shadow Style.Shadow.big
            :: E.clip -- overflow: hidden
            :: overrides -- If the caller provides a different border theirs will override the default defined above.
        )
        [ header conf

So the question is coming from the idea of "components" in the visual sense, like if I define a

btn-primary

tailwind class then do

border-0

will that override what's in the

btn-primary

styles? I've seen this term "layers" floating around which seems to be the solution but in practice I'd wonder "which layer should I be putting this in" maybe? Or is it relatively obvious once you get deeper into it?

You may find you don't need to have custom classes at all (if your button component is in a single file then why have a

.btn

class at all? Just compose the styles directly on the markup with TW classes). But if you do, then you can add them to any of the 3 "layers" - in this case

@tailwind components;

would appear be before TW's utility classes

@tailwind utilities;

, allowing the component styles you defined to be overridden.

Elm looks really complicated! I guess it's what you're used to though. I'm definitely quicker composing with old fashioned html.

Going back to your button; it perfectly possible to create

primary

,

secondary

etc variants in your TW config, and then compose them in your button component. E.g.

<button class="text-white bg-blue-600 primary:bg-red-600 secondary:bg-gray-600 {{ priority }}">{{ title }}</button>

. Could be useful if that is a concept applicable to other components too.

For completion, the TW config would have something like:

js
plugins: [
        plugin(function({addVariant}) {
            addVariant('primary', '.primary&');
            addVariant('secondary', '.secondary&');
    ]

> add them to any of the 3 "layers" - in this case @tailwind components; would appear be before TW's utility classes @tailwind utilities;, allowing the component styles you defined to be overridden. Okay so that is the answer to that question at least Tx!

> Elm looks really complicated! I could say the same about React & JSX "why is it

className

instead of

class

again? Same complexities, same idiosyncratic solutions. 🤷‍♂️ Once you learn a thing it becomes "pretty" because it's familiar. I've seen a LOT of MVC, MVVM, MVU frameworks at this point, and they all look the same to me now 😅 Which is why I'm HERE cause Htmx is like LiveView but for the languages I like on the Backend 😅

Anyways, thanks for all your responses, this definitely gives me a a lot to think about.

if i've learned anything in my 37 years of programming, it's that there are lots of different ways to approach a given problem that, in good hands, all work well

I like elm. It'd be a top choice for an application that runs in a web browser, but I'm sold on hypermedia for web sites. Life is easier with the thinnest client possible.

Yeh Elm has been a breath of fresh air compared to other SPA alternatives but friggin' JSON over the wire is killing me. I just want to take some DB rows and stick em in a

<div />

no JSON, no schemas, no marshalling

{ "name": dbName }

just good ol' HTM~~L~~X

Types are nice up until they get in the way, then they're just a burden. I think a lot of the Typescript SSR frameworks have the right idea about leveraging the languages inference as heavily as possible to ensure contracts over the wire, but what's awesome about htmx is it just removes the need for a contract entirely 🤷‍♂️

I can have my typesafe routing via Servant (haskell), just need to work out a good analogy for elm-ui (tailwind or something like it probably).

Many different approaches, but in the end there's only one solution:

hey we opened at least one mind: https://news.ycombinator.com/item?id=34623218

"Fielding style REST with hypermedia only makes sense for the HTML web where you have a human determining how to navigate from one page to another." in other words, hateaos is for humans

😂 but 😑 but 😞

https://news.ycombinator.com/item?id=34628361 > Maybe once we can run gpt-3 on a mobile phone lightning fast, we can start building these fuzzy, flexible apis and not worry about breaking our clients. But in the meantime, it's a ton of work for very little gain. ngl, one of the comments, of all time

if I have an element like

html
<div hx-get="/asdf" hx-swap="outerHTML">
  <div>
    Some content
  </div>
  <div id="inner">
    <input data-awful-component-that-cannot-be-swapped />
  </div>
  <div>
    Some other content
  </div>
</div>

Is there a way to not swap

#inner

? I tried

hx-preserve

but it didn't seem to do anything. Currently solution is to change the top div to

hx-swap="non"

and return

hx-swap-oob

divs for the content that should update but it's a little unsatisfying

what's happening to the input?

losing focus?