You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When hiccup.core/h is used outside macro-evaluation in 2.0.0-alpha2, it's behavior is different from 1.x:
2.x:
(h "&&&")
=> "&&&"
1.x:
(h "&&&")
=> "&&&"
Since hiccup.core/h used to be a simple alias for escape-html and was no documented expectation (that I know of) that it must be inside an html dynamic context, code that would return hiccup fragments for later inclusion into a hiccup.core/html form is going to have its strings not-escaped.
I don't actually see how it's meaningful and safe to mix hiccup.core/h-using code (written with the assumption that it must escape on its own) with hiccup2.core/html macros--something is going to either not get escaped or get double-escaped.
Possibly this could delay the decision to escape by wrapping the to-string in raw instead? This still won't be the same behavior for those using h just to escape things and will still break code that inspects un-evaluated fragments, but it will make it do the right thing when it is eventually evaluated by either hiccup or hiccup2's html.
The text was updated successfully, but these errors were encountered:
The original idea was to allow swapping of hiccup.core/html for hiccup2.core/html without any other changes, but it probably makes more sense to deprecate h and restore its original behaviour.
When
hiccup.core/h
is used outside macro-evaluation in 2.0.0-alpha2, it's behavior is different from 1.x:2.x:
1.x:
Since
hiccup.core/h
used to be a simple alias forescape-html
and was no documented expectation (that I know of) that it must be inside anhtml
dynamic context, code that would return hiccup fragments for later inclusion into ahiccup.core/html
form is going to have its strings not-escaped.I don't actually see how it's meaningful and safe to mix
hiccup.core/h
-using code (written with the assumption that it must escape on its own) withhiccup2.core/html
macros--something is going to either not get escaped or get double-escaped.Possibly this could delay the decision to escape by wrapping the to-string in
raw
instead? This still won't be the same behavior for those usingh
just to escape things and will still break code that inspects un-evaluated fragments, but it will make it do the right thing when it is eventually evaluated by eitherhiccup
orhiccup2
's html.The text was updated successfully, but these errors were encountered: