Allow HTML in announcement content
Opened this issue · 11 comments
Please allow HTML in announcement title, eg
Latest <b>version</b> available ${name}
Just following up on this, it is somewhat possible when running the custom parser on data and using the built in banner.
The only thing I have noticed in testing is that the spaces around the elements get lost. So the string would have to be Latest <b>version</b> available {% name %}. Note the addition of the character.
But will look at this, although I will make sure people know that they will need to sanitize their content before doing that if they aren't sure where it's from
Right, it would be the dev's responsiblity to sanitize content.
I'm also proposing to consider having content besides or instead of title & link.
content would just be a HTML block. This would make the announcement usable for more use cases. Now it's only a link. It could be just a simple text, HTML text with icons, even a prompt to enter email to subscribe to newsletter. Let the dev put whatever they want. If they want a link, they can put that as <a href="...">...</a>, including setting _target if they want (which I think it's not possible now).
it is somewhat possible when running the custom parser on data and using the built in banner.
In my naivety, I thought this would be done just by setting el.innerHTML, and later https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML
When I made v2 it was designed to allow a person to pass there own rendering options into it through the template option. This was to allow custom HTML, I know it's not in the docs at the moment that might be what you are looking for? That allows for rendering a completely custom thing.
There is the option to actually provide a render class that can return the HTML you want written to the document. As mentioned, these came in on v2, but didn't document them yet.
With using setHTML: I hadn't gone with the setHTML option initially I think cause of the support option, but I hopefully if there is some more browser compat I can slowly add that. It is one of the reasons why I gave provision for using DOMPurify, at least some could have the option. Given that it's on Chrome and some other browsers I'll look at adding it and then give a suggestion if it isn't that DOMPurify can be used.
it is somewhat possible when running the custom parser on data and using the built in banner.
^ the above isn't true now since the adjustment of the issue title. But the below explains more of what I was talking about.
Sorry, clarification on this, the parser is the part that takes what is defined in the templates that have {% json_key %}. The parser takes the HTML <template> and then renders those values and places it in using the el.innerHTML. This is what happens with the render class. Using the templates you can set things like _target.
The attached image illustrates the area in red over the yellow that could have a users custom content placed in the default banner style. Is that the area you were expecting? Let me know, happy to see what can be done.
Thanks for clarifications, Reece!
The attached image illustrates the area in red over the yellow that could have a users custom content placed in the default banner style. Is that the area you were expecting?
Yes!
I think it would be useful to step back and clarify the high level goal of h-bar. IMHO, it focused on a very narrow use case: Load JSON from an URL to display a link (with implementation having a template engine included).
A larger use case would be: Display one or more announcements (one at a time), given as HTML content.
This would cover my use case and many others, including the original (but not forcing it). Examples:
- a simple text announcement ("Happy Holidays!")
- a link (what it does now)
- text with multiple links ('Please support us on Patreon or by purchasing the book')
- complex HTML (one-line newsletter signup form)
It's easy for the developer to use a templating engine if they wish (eg Handlebars) to produce that HTML, or get the content (JSON or HTML) from an API. These could even be in h-bar examples, but not bundled in the library.
If you think 'Display some HTML' is too simple, I'd still prefer to use a library instead of rolling my own. It needs to
- look good on phones and desktops. This includes not only the margins, but maybe even font size
- smart font sizes: larger for short announcements, smaller for long ones (try to fit on one line on phone/desktop)
- be closable in a smart way: not show again the same announcement when navigating to another page, but another announcement which wasn't closed
- have a flexible bar height depending on content (not limited to a fixed height) -- I guess this just works as long as height isn't hardcoded
I also liked the themes and badges support, which I wouldn't have thought about.
What do you think?
Implementation note:
The constructor could take an announcements attribute such as
[
{ content: "Happy holidays!" },
{ content: "Happy holidays!" },
...
]Note that this doesn't directly provide a list of HTMLs, just in case each announcement might have some other options in future.
Hi, thank you for the suggestions on the package. It was intended to be a simple solution initially, but I am open to extending it and happy to have this feedback.
I've been going over the suggestions above and will come back here to this thread, thank you for them, I wasn't ignoring them 👍
Thank you Reece! Happy holidays :)
Hi Reece, hope this finds you well. Curios to learn about your decision. Thanks
Hi Marius, the message does find me well :) hope the same goes for you 👍
I just had a bit of a busy month and a bit pushing features out for a client but I'm happy with where this feature would go for the package.
Great, thanks Reece!