https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • l
    @mysterious-toddler-20573 ah yea, you're grabbing only the 1st item in your fosterparenting work-around
  • l
  • m
    me, addressing html parsing quirks:

    https://www.youtube.com/watch?v=P9yruQM1ggc▾

  • l
    What's lovely is all of this deep knowledge can be encapsulated and given a clean interface 😉
  • l
    ie, then at least it's not my monkey... or well, gorilla.
  • m
    🙂
  • b
    Any timeframe for 1.0.2? Seems like it would be a nice and contained update to add these quality of life improvements: https://github.com/bigskysoftware/htmx/commit/b1729b2b8573c7692d463ce1b81306573ca5492d
  • m
    end of next week? I'd like to get https://github.com/bigskysoftware/htmx/pull/253 reworked and merged, and I can take care of that next week
  • b
    Ok, but FYI small quality of life updates are like 🎁
  • m
    OK ben you guilt tripped me into getting 1.0.2 cleaned up and ready to go
  • m
  • b
    Wasn't my intention, but this looks like a solid release!! https://github.com/bigskysoftware/htmx/blob/dev/CHANGELOG.md#102---202--
  • l
    I have a tangential question and was wondering if this community could help. For the Julia language I built a clone of mbostock's "hypertext literal" (https://observablehq.com/@observablehq/htl).
  • l
    Only that HypertextLiteral.jl (https://github.com/clarkevans/HypertextLiteral.jl) works server-side, converting Julia objects to HTML.
  • l
    Now my question. Suppose my markup contains 
    <tag att=$obj/>
    . Should the conversion of the server-side object 
    obj
    be determined just by the type of the object, or should it be determined based upon the "(attribute-name, object-type)" pair??
  • l
    There are a few edge cases. They could be handled universally. For example, if 
    obj
    is an 
    Vector
    it could be expanded to a space-separated list of its components (this to support 
    class
    and a whole set of space separated token cousins).
  • l
    If 
    obj
    is a 
    Bool
    , it could either keep the tag or remove it, following boolean attribute semantics.
  • l
    If obj is a 
    Dict
    it could expand to match 
    CSS
    sensibilities, e.g. 
    style='color: blue; ...'
    .
  • l
    My question is, should these be universal translations dependent only upon the object being serialized, regardless of the attribute type. Or should they depend upon both the attribute name and the object type? ie, flexibility vs consistency
  • l
    I implemented the flexible approach, but I'm thinking I should rip it out and go for consistency.
  • l
    Any thoughts, especially as they may apply to HTMX, would be great. Would similar objects ever want serialize differently based upon the attribute they were used with?
  • m
    i like consistency, with an explict mechanism if you want a different seralization mechanism
  • m
    If you want a map to be a boolean, you get what you deserve
  • m
    😉
  • f
    I'd say consistency would make it easier to debug...
  • f
    Also ... I've just created PR with some SSE related madness ...
  • f
    My grasp on what's going on is .... tenuous ... so I'm pretty sure that I'll need to evolve what I'm doing quite significantly ....
  • f
    And also, I'm convinced I'm straying outside of the bounds of what HTMX was intended to do in the first place ...
  • f
    So for both of those reasons (the latter more than the former) ... I'm not actually suggesting that my PR should be accepted.
  • f
    However ... I'd like to use it as a launching-off-point for a discussion so I can maybe find a better way to do what I'm trying to do...
1...939495...1146Latest