It does NOT work, but maybe it’s my implementation:
Added to the one point in my paragraph where I want the line break here: （クリックでサイレン音を試聴） 業界最小サイズの125dB防滴ネオジサイレン。耐熱、防塵、防沫、IP54。新基準「BEEP」1トーンサウンド。アメリカン６音色も選択可能。
Ok, just did a quick test in both Blocs v5 and Blocs v6.
Saying that data-attributes use “Plain Text” is not entirely accurate.
If you drop a Bloc on a page and give it a data-attribute of A B and then preview it and inspect/view source you end up with data-whatever="A B".
So Blocs like many other places is setup to strip out special characters and not honoring plain text here. Otherwise it would work, as your Japanese text works correctly in the vanilla example.
As shown in the vanilla example its not an inherent issue with native data-attributes. Instead it’s what Blocs is choosing to do for users and how it was coded as an app to strip special characters out.
Vanilla data-attributes can handle a multitude of entries, not sure why the guardrails are in place here within Blocs. That would need to be changed in order for this approach or other data-attribute abilities to work.
Good luck, sorry it didn’t work in Blocs with “plain text”.
It probably would take @Norm the same amount of time to “remove the guardrails” as it would for him to just support carriage return “line feeds” outright, so that may be the best approach. And to better ensure that will happen, let us boldly say what needs to be said…
To be clear a physical carriage return, <br>, \n, \r, etc., inside a data-attribute will all not work as intended, thus the suggestion of the unicode line feed , (or 
) for it to work.
But yes lets see what reduction of stripped special characters occurs for data-attributes within Blocs going forward.
I have been using the “Image Map Experiment” by @norm for a little over a month now. It took what seems like an eternity to fully switch one of my 4 big Blocs documents to BS5, but I finally did it, eradicating jQuery dependancies with the help of ChatGPT rewriting code for me. Yes, yes, I know we can link to jQuery, but I didn’t want to add that bloat. BS5 seems to be about starting fresh, so I sought to achieve that.
Hovering over those blue dots to make overlays displays works well in most cases, but there is one case where it falls down flat. When a small screen smartphone is browsing the web in landscape orientation, there’s insufficient vertical height to show the text overlay, and the overlay is not smart at all — it won’t auto-center.
You can try it out yourself on my implementation here (BS5 site):
Start with a big screen and mouseover the blue dots to see how the overlay works. That should look like this…
Note how everything works perfectly on mouseover, with that text overlay never overlapping any of the blue dots.
Now create an iPhone 8 in Landscape in Blocs’ Preview, then bring all blue dots into view, then try to mouseover the dot in the lower left. The text popover never centers in the screen, so it gets truncated like this…
And yes, I have tried to make that popover content appear in the center, but my attempts to do that were thwarted by the popover content then starting to overlay the dots!
Maybe there’s another trick here I’m not thinking of though, hence my desire to share my findings will all of you.
Works perfectly. Thanks @Norm. But for mobile, I decided to use just an image link which opens a modal. I noted that in small window, when the points are too close one from each other, it does not work properly.
I see that the dots change to A, B, C, etc. I don’t see that as a problem, so long as people know those letters are things they should click/tap on, especially because those letters are (1) small and (2) the same color as unclickable explanatory text on that map.
When I click/tap on any of those tiny letters, I can see your modal…
What was my previous post saying that I am also saying here too? Well, I am saying it would be nice to have that popover content always appear in the active window area. What is the best way to approach that solution to this truncation problem?
Thanks @JDW for your thorough testing !
Sorry for the late answer, I was away.
The only precision I have to make is that on mobiles (portrait) it is a single image and letters replace the active spots of the interactive map. In fact a touch on the image, anywhere, not only on the tiny letters, display the popup window the legend.
Because, and you’re right, the letters or the active sports would be too close from each other and too small.
I understand the problem of the truncation on smaller screens. But I assume very few people use their mobiles in landscape mode. For sure it would be nicer to have the popovers display inside the active window.
Thanks @Norm for the suggestion of using a full screen bloc with a close button.
I might try that later because the client uploaded the website on their server on which I don’t have access. When they ask for an update, I’ll work on that interactive map.
Hey @JDW, just a quick follow up on this post from earlier in the year.
The latest beta of Blocs for Mac 6.3.1 (build 4) now includes support for basic html text formatting in custom data attributes, so you can now add line returns, bold tags etc.
It’s still in beta so you may encounter some tags that cause problems.
There is also a new rule to use to ensure the tags are injected properly.
Use the new Set HTML Custom Interaction Rule to set the values rather than Set Text.
I used this example to create a mini presentation website. All the buttons work fine except for the one for the weather “meteo”. It links to a modal window containing code. I’ve tried everything, but the modal window won’t appear. An idea? @Norm
