The current behaviour of HTML collapsing all whitespace and removing all new lines is most likely caused by the fact that in HTML whitespace is used for both formatting the source code and, well, actually rendering the spaces between words. Elm doesn't have mix these unrelated concepts, as only strings are rendered.
I propose that we should never collapse any whitespace and keep all new lines. For a newcomer, this would be the expected and natural behaviour.
A personal example. In my last project, we had a <h2> element which upon double-click turns into an element, which is styled and aligned so that the only difference between the two is the text cursor. The text is always perfectly aligned, unless there's double whitespace in the header. <input> preserves all whitespace (and <textarea> preserves newlines). The desired behaviour here would be to always render all whitespace and newlines.
This can be easily implemented via white-space: pre-wrap, or white-space: pre if we want to keep the text in one line (also see #19).
The current behaviour of HTML collapsing all whitespace and removing all new lines is most likely caused by the fact that in HTML whitespace is used for both formatting the source code and, well, actually rendering the spaces between words. Elm doesn't have mix these unrelated concepts, as only strings are rendered.
I propose that we should never collapse any whitespace and keep all new lines. For a newcomer, this would be the expected and natural behaviour.
A personal example. In my last project, we had a
<h2>element which upon double-click turns into an element, which is styled and aligned so that the only difference between the two is the text cursor. The text is always perfectly aligned, unless there's double whitespace in the header.<input>preserves all whitespace (and<textarea>preserves newlines). The desired behaviour here would be to always render all whitespace and newlines.This can be easily implemented via
white-space: pre-wrap, orwhite-space: preif we want to keep the text in one line (also see #19).