Max Desiatov

@rbartolome I'm sorry, but fixing this will require signifcant changes to our `Picker` implementation, and I'm working on it right now. I would advise you to use an `Int` binding...

If have something like `ElementAttribute`, it won't work for custom attributes if there are no associated values. Maybe it would have a separate `case custom(String)` to support those? As for...

Something like `dom_` would be basically switching these names to snake_case, which is not common in Swift, which is predominantly (if not completely) camelCase. I do think something like `_dom`...

Can you elaborate please? What's your use case?

I think the safest way is to use `DynamicHTML` to create a new button from scratch with a correct `id`. What HTML elements and attributes `Button` uses under the hood...

Yes, exactly. If there's a need for a given view (or `Router`) to adjust anything (most of the time it would be the `` content) a given `App` could expose...

That's a great point, but I previously haven't written any SwiftUI apps for macOS, so I don't even know how that's supposed to work to propose anything concrete on that...

Right, I started thinking of `` because I tried to imagine how `` changes could be integrated with the new router, I'm not sure it would be that easy if...

IDK, the title can be dynamic already if only the router supported title bindings: ```swift struct MyApp : App { @State var title: String var body: some Scene { WindowGroup(title)...

@carson-katri could your [swift-css](https://github.com/carson-katri/swift-css) package become relevant in any way?