It’s only needed at compile-time, not runtime, I deploy to a rust-less docker alpine container without issue.
OvermindDL1
tmbb
It does.
It doesn’t support this by default, but you can hook some callbacks to avoid this problem. I think…
You and the 4 other people here who know what OCaml is xD But yeah, that’s the tradeoff for strong typing: you reject some sound programs (yes, it’s possible that the totally untyped string the user passed into the template is valid HTML!) in exchange for better guarantees.
The main issue here is that it’s not that obvious how to support tags with attributes with dynamic keys. But yeah, it’s a restriction few people will hit in practice.
mischov
People using Floki generally go with the default parser which is the Mochiweb one- particularly people using Floki as part of a library, so the library’s users don’t need to have Rust deps. I’m not sure Floki’s html5ever parser is even working on the latest OTP?
Floki (with the mochiweb parser) generally fails with incorrect HTML, or rather, in how it parses HTML that is “valid” HTML5 but may get moved around.
Edit: Simple example:
<html><head></head><title>Hello, TEA</title><body></body></html>
Parsed by Floki with the mochiweb parser to:
{"html", [],
[{"head", [], []}, {"title", [], ["Hello, TEA"]}, {"body", [], []}]}
Parsed by Floki with the html5ever parser to:
{"html", [],
[{"head", [], [{"title", [], ["Hello, TEA"]}]}, {"body", [], []}]}
OvermindDL1
So let me guess, you’d “Build In” some known ones like textbox, and leave custom elements up to the user to implement via some other plug that they’d have to do or so? That sounds remarkeable painful when it’s otherwise simple attribute/property changes on them… o.O
Speaking of, I’m not seeing an immediate way to distinguish between attribute or property updates in that library?
If it’s using the firefox HTML5 parser, I don’t see how that would happen though. ^.^
Actually that’s a super common use-case at work. We use an excessive amount of custom elements along with is="..." enhancements to have full support for javascriptless things like old screen readers we have to deal with to newer things to evergreen, it works fantastically. 
I know html5ever is working on the OTP 21.1.1 as I’m using it.
Do you have an example though, I’ve not run in to any such issues in Drab as of yet. (NinjaEdit: It looks like Drab is set to use floki with html5ever on my server, so that might be why I don’t see issues?)
mischov
Edited above to include, but here’s simple example.
<html><head></head><title>Hello, TEA</title><body></body></html>
Parsed by Floki with the mochiweb parser to:
{"html", [],
[{"head", [], []}, {"title", [], ["Hello, TEA"]}, {"body", [], []}]}
Parsed by Floki with the html5ever parser to:
{"html", [],
[{"head", [], [{"title", [], ["Hello, TEA"]}]}, {"body", [], []}]}
tmbb
Ok, but that makes some optimizations difficult. Although is the goal is to render things intos a JSONPatch I guess that’s not a big problem, as I’d have to have a map to send to the JSON encoder anyway. But it’s a problem with my string-based templates (I can render it dynamically, I just can’t optimize it).
I think you’re the only human in the whole world for whom that distinction matters 
I’ve learned it from you, and aside from your bucklescript-tea repo and the js library that inspired it (https://github.com/Matt-Esch/virtual-dom), I haven’t seen that distinction anywhere. So, no, it has no ways to distinguish it. I guess that if I must implement my own VDOM I need to understand the distinction, right?
OvermindDL1
Actually it is extremely common as changing the wrong one on certain elements will not work (or in some notable cases throw an exception). Everything from my tea library to vue.js to polymer to react to near everything I’ve ever seen has the distinction. Most will often build in known mappings so you don’t have to deal with it on things like className and so forth, but they all have ways to override it as well since custom elements are of course custom, thus only the author of the site can known for certain hence why a way to specify which to use must always be necessary (and yes, Drab has a way to specify as well).
tmbb
Regarding the part where input components might be overwritten, how do you propose to solve that without special logic on the client? By customizing the patches on the server so that they never edit the value of input tags? Isn’t that the same as the whitelist approach you don’t like?
tmbb
tmbb
From what I’ve found, it seems like the bottleneckin morphdom is parsing HTML strings. But morphdom has a spec for compatible VDOMs. Maybe if I send JSON encoding a VDOM (which will require some processing by client-side Javascript) and it will be fast? I have to ask it in a morphdom forum.