New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useHTML: true VS useHTML: false #7126

Closed
schneckentempo opened this Issue Sep 4, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@schneckentempo

schneckentempo commented Sep 4, 2017

Some followup to #7092
that was worked around with useHTML everywhere where text was used and lead to #7114
which now is causing tooltips to be overlayed by data labels

Actually we do not want to use useHTML anywhere if evitable, but we now have to work around workarounds. I like to ask for a revisit of the special character and html tag handling when useHTML is actually false (default)

Expected behaviour

case without useHTML:
looking at name it should simply display whatever is put into the text - & &amp; &lt;text 1&gt; <text 2>

case with useHTML:
in my opinion when this option is set to true the input should be decoded if &lt;, &gt; or &amp; is used but also should display &, < and >. Text between < and > should be interpreted as html tag, while between &lt; and &gt; should not

Actual behaviour

case without useHTML:
looking at name & and &amp; are shown correctly. &gt; and &lt; are decoded and <text 2> gets hidden because of interpretation as a tag

case with useHTML:
& and &amp; get displayed both as &, again &gt; and &lt; are decoded and <text 2> is also hidden

Live demo with steps to reproduce

with useHTML: http://jsfiddle.net/c392mf1q/2/
without useHTML: http://jsfiddle.net/c392mf1q/3/

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 5, 2017

Collaborator

Thanks, but I'm not sure I follow. I would expect this to work equally with or without useHTML so that switching between shouldn't affect how things are rendered:

  • & renders as &.
  • &amp; renders as &.
  • &lt; and &gt; are rendered as < and >.
  • <text in tag> is interpreted as a tag and hidden.

This is how it works after the fix for #7092: http://jsfiddle.net/highcharts/c392mf1q/4/

Collaborator

TorsteinHonsi commented Sep 5, 2017

Thanks, but I'm not sure I follow. I would expect this to work equally with or without useHTML so that switching between shouldn't affect how things are rendered:

  • & renders as &.
  • &amp; renders as &.
  • &lt; and &gt; are rendered as < and >.
  • <text in tag> is interpreted as a tag and hidden.

This is how it works after the fix for #7092: http://jsfiddle.net/highcharts/c392mf1q/4/

@schneckentempo

This comment has been minimized.

Show comment
Hide comment
@schneckentempo

schneckentempo Sep 5, 2017

I would expect <text in tag> to be not interpreted as a tag and hidden if useHTML: false

schneckentempo commented Sep 5, 2017

I would expect <text in tag> to be not interpreted as a tag and hidden if useHTML: false

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 6, 2017

Collaborator

Why would you expect different behaviour? To me that is counterintuitive, the ultimate goal should be that the SVG pseudo-HTML behaves identical to true HTML.

Collaborator

TorsteinHonsi commented Sep 6, 2017

Why would you expect different behaviour? To me that is counterintuitive, the ultimate goal should be that the SVG pseudo-HTML behaves identical to true HTML.

@schneckentempo

This comment has been minimized.

Show comment
Hide comment
@schneckentempo

schneckentempo Sep 6, 2017

But semantically a prop named useHTML: false indicates, that there is (no matter what) no html rendered, while useHTML: true indicates to me I have to take care about what I put in.

I am no professional when it comes to SVG. Maybe you can explain me, why there is a useHTML option, what it actually does and why the goal should be the general usage of html elements in textfields. What does this make better for the users of the library?

schneckentempo commented Sep 6, 2017

But semantically a prop named useHTML: false indicates, that there is (no matter what) no html rendered, while useHTML: true indicates to me I have to take care about what I put in.

I am no professional when it comes to SVG. Maybe you can explain me, why there is a useHTML option, what it actually does and why the goal should be the general usage of html elements in textfields. What does this make better for the users of the library?

@pawelfus

This comment has been minimized.

Show comment
Hide comment
@pawelfus

pawelfus Sep 7, 2017

Contributor

Explanation of useHTML and general formatting rules can be found in our docs.

I agree with @TorsteinHonsi, the output should be consistent, it doesn't matter if we set useHTML or not. I am pretty sure it will be reported as bug shortly after the release if we change that.

Contributor

pawelfus commented Sep 7, 2017

Explanation of useHTML and general formatting rules can be found in our docs.

I agree with @TorsteinHonsi, the output should be consistent, it doesn't matter if we set useHTML or not. I am pretty sure it will be reported as bug shortly after the release if we change that.

@schneckentempo

This comment has been minimized.

Show comment
Hide comment
@schneckentempo

schneckentempo Sep 7, 2017

The following tags are supported: <b>, <strong>, <i>, <em>, <br/>, <span>

I do understand that this behaviour may be wanted, but not for definitely non html tags eg.:
a < b and c > d which would output a d - this can't be a desired behaviour

then why not a disablePseudoHTML or usePseudoHTML prop?

schneckentempo commented Sep 7, 2017

The following tags are supported: <b>, <strong>, <i>, <em>, <br/>, <span>

I do understand that this behaviour may be wanted, but not for definitely non html tags eg.:
a < b and c > d which would output a d - this can't be a desired behaviour

then why not a disablePseudoHTML or usePseudoHTML prop?

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 11, 2017

Collaborator

this can't be a desired behaviour

As far as I can see, a < b renders correctly in both cases: http://jsfiddle.net/highcharts/c392mf1q/7/

Collaborator

TorsteinHonsi commented Sep 11, 2017

this can't be a desired behaviour

As far as I can see, a < b renders correctly in both cases: http://jsfiddle.net/highcharts/c392mf1q/7/

@schneckentempo

This comment has been minimized.

Show comment
Hide comment
@schneckentempo

schneckentempo Sep 11, 2017

seems a < is seen as a tag when useHTML is set when there is a < followed by a character, without it's always a tag

http://jsfiddle.net/c392mf1q/9/

schneckentempo commented Sep 11, 2017

seems a < is seen as a tag when useHTML is set when there is a < followed by a character, without it's always a tag

http://jsfiddle.net/c392mf1q/9/

@TorsteinHonsi

This comment has been minimized.

Show comment
Hide comment
@TorsteinHonsi

TorsteinHonsi Sep 11, 2017

Collaborator

I've fixed this case now. If you come across more cases of bad parsing please note them here and we'll consider them, but also keep in mind that we're not rebuilding a perfect HTML parser. For example, in true HTML the code a <b and c> d makes the d bold. Our HTML parser doesn't do that because it expects a closing </b>.

Collaborator

TorsteinHonsi commented Sep 11, 2017

I've fixed this case now. If you come across more cases of bad parsing please note them here and we'll consider them, but also keep in mind that we're not rebuilding a perfect HTML parser. For example, in true HTML the code a <b and c> d makes the d bold. Our HTML parser doesn't do that because it expects a closing </b>.

TorsteinHonsi added a commit that referenced this issue Sep 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment