When I set the text with carriage returns (using option return) in the Success and Fail message boxes of a form, they are removed when the messages are displayed on screen leaving poorly laid out text.
Because this message is stored as a data attribute value, you can use a line break tag eg. <br> otherwise it has no way of knowing you want a new line here.
Great, thanks!
I don’t know if this is the problem, but you’re using 2 break tags next to each other rather than one.
Yeah, because I want a line between the sentences.
I haven’t tried, but I thought the double break may mess up a single break tag. Just trying to help…
Nah, I get you’re trying to help, I am not sure either; I don’t see why two breaks wouldn’t work, but hell, everything about website building seems like a crap shoot of illogical stuff anyway.
Does it work correctly with one, but not two? Working at all would demonstrate inconsistency throughout the app for data-attributes, given the following.
https://forum.blocsapp.com/t/image-map-experiment/26078/18
So was surprised to see what Pete posted above as working.
It works correctly with two on a different modal form on a different page.
I’m about at the point where I sacrifice a chicken, turn around three time and spit every time I try to do something… there is no consistency I can see - and I’m not knocking the awesome Norm or maybe even blocs but website generation and building itself.
I’ve tried sitely, elements, blocs and even wix and nothing is simple or works like it should. Too many cooks making up web tech and no oversight.
Yep. Just being lazy with unescaped markup. I was surprised it worked too
non reliably at best. I was actually expecting that input field to be highly sanitised ![]()
Spare the chickens.
![]()
I don’t really prescribe to the same notion or that most the internet is a hack. Instead web standards are straight forward and solid, the issue occurs mostly when visual app approaches abstract away from these standards. Therefor vanilla dev is bliss, no abstraction, but a visual approach is the unicorn
most desire, but there are often lots of trade-offs.
I can imagine.
How many websites have you coded up this year?
Maybe best instead to focus on giving consideration of the direct topical aspects of Blocs being spoken about here ( data-attributes ). What are your thoughts on possibly addressing those to not limit them as much ?
If that is intended for me, I have no idea what you’re asking, let alone a response.
Of course ![]()
When I first visited the post it looked like there was a solution so I moved on, later in the day I revisited, noticed it was still a problem, so I began my plans to implement a potential fix.
I thought I would follow up when I had more details or a solution.
Anyway, your response was the last I read and it got me thinking ![]()
You’ve been here a while and I don’t recall you ever sharing any websites that you have created, so I thought I would enquire.
I know a few developers who build websites, using vanilla development methods and I don’t think any of them would describe it as bliss.
2016 it was, we’ve previously enjoyed lots of “private” talks as you advanced the app(s).
Concerning data-attributes, like I said previously in 2017 – so I’m just glad to see the data-attributes feature finally get this type of improvement after entering the app in 2018 within Blocs v3. Thus the continued discussion around them when I see topics, as they are super useful.
They can likewise support far more than “basic html text formatting”, perhaps they can be opened up more down the road. This is an advancement so – good job. I’m sure @JDW will be happy that it got added.






