lack of type safety in attributes

[joeyh]

My first threepenny program had a bug that I was surprised was not prevented at the type level. Here it is:

import qualified Graphics.UI.Threepenny as UI
import Graphics.UI.Threepenny.Core
import Text.Password.Strength (estimate)

main = startGUI defaultConfig $ \window -> do
    prompt <- UI.input
    estimatedisplay <- UI.string ""
    getBody window #+ [ element prompt, element estimatedisplay ]
    promptIn <- stepper "" $ UI.valueChange prompt
    let showEstimate = show . (`estimate` []) <$> promptIn
    element estimatedisplay # sink value showEstimate
    return ()

The bug is that changing the value field of a UI.string has no effect, so the password strength estimate never gets displayed. The fix is changing "value" to "text".

Seems that it would be good improvement to only allow setting attributes that html elements actually have.

[HeinrichApfelmus]

Type-safe HTML elements and attributes are a good idea, but the question is whether the implementation cost in terms of additional and maybe confusing type signatures is worth the benefit. At the moment, I lean towards the "sadly no" side, but I'm happy to be convinced otherwise by a prototype implementation.

A type-safe implementation of HTML combinators has been described in the paper

"A typed representation for HTML and XML documents in Haskell "
P. Thiemann, J. Funct. Prog. 12, 2002 (2001)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.3444

Of course, one doesn't have to go the "everything type-safe" route; it's also possible to encode just a few invariants which occur often in practice.