[ENHANCEMENT] Allow the possibility to add static HTML to begin and end of output.

[iwaumans]

I would first like to thank you for this visual! It has changed a lot for me and I have been able to develop some very nice visualizations!

For instance this one, showing how students evolve through their study program:

And a dashboard to interact with the Wifi access points in our college university:

It would make things a lot easier if it were possible to add 'static' HTML to the beginning and the end of the output. In short: the ability to wrap code around the output. This way I could add things like a header for a table. I tried developing a way to find out if a row in the output is the first row (in order to inject it conditionally). I have a complicated model using both data in import as direct query mode, and I have a lot of trouble getting this to work. This could - for example - be implemented by adding 2 fields ('Header HTML' and 'Footer HTML') underneath the Granularity field?

In a video (from about 4 years ago, in collaboration with powerbi.tips), I saw you demonstrate the advanced edit mode for your visual. You talked about a version 2 (in development). The functionality you showed there would also solve my 'problem'. Are you still working on this?

Looking forward to your answer!

[Shadowfita]

Would having this available as an option assist in bypassing some of the character limits? E.g., could I add some static scripts / library setups in this static HTML "field" and then populate everything else via measures, effectively bypassing a measure's 2.1m char limit?

[dm-p]

Apologies for the delay in responding, and thanks very much for sharing your examples - it's great to see just how far folks can push the visual to achieve what they want!

Regarding the "v2" demoed in that video a while back: the feedback I got around the time was that while it was a nice idea, it would be better to solve some other challenges around styling, and this would unlock most of the blocking challenges folks were having. So, the UI idea was re-purposed into Deneb, and because Deneb takes a lot of work to maintain and support, I don't think I could sustain the development three visuals (as HTML Content has two editions to support) with an advanced UI in my spare time and keep them free and open source.

Therefore, if this were to be done, I think it might need to be a handlebars-esque solution where we maybe have two templates available in the visual properties. I'll add my thinking here so that you can review and see if it works for you. You're very welcome to expand or correct the idea based on how you think it will (or should) work for your use cases. However, please bear in mind that it will need to work for all users and ensure that we don't break existing content when the visual updates are made.

1. Top-Level Template

By default, this would take the content we hard-code in the visual and make it more flexible, i.e.:

<div tabindex="0" id="htmlContent">
    {{content}}
</div>

The visual would replace the {{content}} with the generated content as it works currently. This would allow you to add preceding and trailing content around the dynamic content. Of course, you would need to ensure that if you open a tag before the {{content}} token, then you would need to ensure a suitable closing tag in the trailing content for things to parse correctly.

2. Granularity Template

This would represent the rendered content for each row of the dataset (which, if using a measure, would be a single row). This would default to the current row-level content in the code, e.g.:

<div class="htmlViewerEntry">
    <div>{{row}}</div>
</div>

The default content would ensure backward compatibility for anyone not wishing to utilize these changes, but this would then allow you to change out what gets rendered for each row (if adding a column to the Granularity data role, or the single row if just using a dynamic measure with the Values data role). The {{row}} token would be the HTML you were supplying. This means that you could remove (or change) the surrounding <div/> tag for each row in the dataset.

However, for compatibility with things like tooltips and cross-filtering, you would need to preserve each row with a suitable enclosing tag so that the visual logic can bind these correctly. In other words, you will need to ensure you have set this up properly, rather than me.

---

And a couple of general remarks regarding such a potential change:

• We should probably have visible properties in the pane for these changes, with the option to allow their population via conditional formatting, like we do with the stylesheet:

  

• If we implement Handlebars, we should be able to leverage a lot of their additional features, like conditional blocks and looping, which could potentially introduce some interesting utility in combination with templates for top-level and granularity. We could also register additional helpers, which may help with easier scaffolding of things like interactivity, or hook into visual calculations.

• As a heads-up, the certification of 1.6 is currently blocked due to the markdown changes introduced there. I'm working through these, but we may have similar challenges with adding and allowing these proposed features in the certified edition. I'd aim for feature parity, but may have to review/compromise accordingly as we go through the certification process.

• Given the details about the certification holdup, this gives us some time to flesh this feature design out, so please add your thoughts, as if we go ahead with it, it will be hard to course-correct once it goes into AppSource, as it then becomes a challenge of making sure we don't break existing reports for everyone.

[dm-p]

@Shadowfita: I'd be very interested to know how/why you're hitting content limits, given that scripting isn't really supported. If you're getting this to work, would you be willing to share an example or contribute a short overview explaining how it's done? If so, I might be able to document this for other users.

[Shadowfita]

@Shadowfita: I'd be very interested to know how/why you're hitting content limits, given that scripting isn't really supported. If you're getting this to work, would you be willing to share an example or contribute a short overview explaining how it's done? If so, I might be able to document this for other users.

Absolutely! Firstly, thank you for your in-depth response on the original topic. Secondly, I hadn't realised you were also the lead on deneb, so thank you very much for all of the work you've done for the open-source community, providing such powerful visuals for us to use in PowerBI.

Regarding scripting, I found that most scripts and libraries worked with some minor changes to the events they rely on for functioning or initialisation in the 'full' version of the html content visual. I've been able to bring in both scripts and css for tailwind and the tailwind component library Preline.

I've borrowed your naming conventions:

---

Inline scripts, minified and modular selection for required components and functionality from jsdelivr.com:

---

Collated each group of code into the "required" measures to make it easier to maintain:

---

This has allowed me to render fairly comprehensive dashboards and charts using ApexCharts, while also maintaining cross-filtering, etc. Here's an example page (whole page currently one html content visual):

---

In my testing, I'm able to use pretty much all scripting functionality, including buttons, dropdowns, etc, from these libraries. It has required a bit of workarounds and compromise though to ensure cross-filtering works from html components though. Like I don't think I will be able to achieve cross-filtering with a select input, so will need to opt for another component.

So as a result of trying to cram in many libraries, and particularly verbose libraries like tailwind and icon libraries, I've quickly hit the character limits, haha.

[iwaumans]

@dm-p Thank you for your reply! I understand the amount of work it takes to create and maintain such a project, so I truly appreciate you taking the time to reply to my request (and to keep the visual free and open source).

Concerning your thoughts about a possible implemetation, I love the idea of using handlebars. But to be honest - and this is coming from an experienced perfectionist (read: 'spending a crazy amount of time on details') and dreamer (read: 'getting very excited when I realize the potential of some new thought') - I also think it might be overkill. The visuals already offers a lot of flexibility because of the granularity feature. So I have no specific/additional needs on row-level.

Keeping in mind backward compatibility, wouldn't it be quite simple to implement the feature like this?

The 2 fields can remain blank for most users. But when content is provided, the preceding HTML is placed between the default content opening div (id = htmlContent) and the generated HTML. And the subsequent HTML is placed after the generated content and before the closing div.

I am a big fan of the Pareto principle. With 20% of the time, you can cover 80% of the need. If later, you would like to go a step further, and implement a handlebars based concept, you could include an "Advanced" option which you could toggle. This would disable the preceding and subsequent HTML fields en reveal a field with the code containing the handlebar. From there you could build on the features like conditional blocks and looping. In this case, the "Top-Level Templates"-concept speaks to me the most.

These are just my thoughts. I hope they will help you to make a decision. Whatever you decide, I will be a fan and continue to be very grateful!