Then you need to use the text function (String -> Element)
to make that link appear properly on the screen.
This means that the text function (intentionally?) does not HTML-escape strings, even though examples suggest that it is the recommended way to put some unformatted text on the screen.
Looks nice overall, and I look forward to seeing how it develops. Is Elm available for download?
- Why is text necessary?
Elements are all rectangles that have a uniform set of functions that can be applied to them. Strings are definitely not rectangles, and I think it is important that the type of String and Element are not conflated. In that case what does (++) do when given an Element? It just wouldn't work out.
- Why is text unescaped?
That's pretty much an implementation oversight from when I was first starting the project. Strings should be exactly what you intend to display. I have been meaning to go back through and fix up the underlying string representation, but I just don't have time right now. I have been focusing on the theoretical aspects of reactive programming for my thesis which is my main priority at the moment. Nonetheless, this will be fixed eventually!
- Why (link :: String -> String -> String)?
My thought when I designed it this way was that part of what it means to be a string includes styling (bold, italic, etc.). Following this idea, this would have to be true of characters as well, so (head (link "/" "Elm")) would give you a character that is a link. I honestly think that's a little weird. I,ve gotten questions about this before, and I'm not exactly sure what the right answer is. The other option is to include an intermediate type of strings that does include style information, but then you need to lift normal strings up to this type to do concatenation (unpleasant). Doing this right is going to be really hard, and I haven't given it the time to really figure it out. I'll probably include ways to use markdown (or HTML) which will alleviate some of these issues. If you have suggestions on this topic I'd be interested to hear. It's harder than it looks :P
Also, let me stress that this project is VERY young, so there are still many kinks to be worked out. There is no download available now. With upcoming thesis deadlines, I probably won't have one up until spring of next year at the earliest. Thank you for your interest! I'm working as fast as I can!
I would keep String and StyledString separate. Lifting to a StyledString is okay if you want to concatenate a String and a StyledString.
(plain "This is ") ++ (bold "GREAT!")
-> StyledString "This is <b>GREAT!</b>"
Strings are used for more than just rendering HTML, and I should be able to forget about styling in situations where styling is irrelevant.
"partial serialization of something..." ++ " another chunk"
-> "partial serialization of something... another chunk"
One immediate benefit of keeping String and StyledString separate, is that you won't forget which argument comes first in link.
link :: (String -> StyledString -> Element)