It should be easy to create a plugin for those who want the old behavior. But I find I spend too much time finagling things to get everything just right--and this new approach just works.
It's possible the original system could be improved, but it's not near as easy as it sounds. There are an infinite number of possibilities of what can appear in a line and many things you shouldn't wrap in p tags: headers, list items, blockquotes, etc. And some lines may or may not contained includes or escaped content. It's about as smart as I know to make it, and I'm not sure it's even possible to solve it 100%. It's just the nature of how these tags work. I could explain this more fully if you want, but I've wrestled this for many years, and it's my honest conclusion. As for styling, this can be managed essentially the same, because all text is contained within divs which can be styled to control line-spacing etc. You could always manually insert the p tag in special situations, and the dot would just be a shortcut for that. But it's not really needed. I don't know how it would impact accessibility but my guess is, readers have to be able to scan divs, tables, blockquotes, and other elements that are not normally wrapped in p tags, or much of the content on most sites would not be accessible either. So I'd have to see a real use case where this has an adverse impact. On my site the display is almost perfect. The only exceptions are where I've already finagled things, and I just have to go through and remove all those tweaks. It's quite impressive how simple it is. I will definitely include a plugin however. Cheers, Dan On Wed, Aug 12, 2020 at 2:11 AM mz <tcc.pla...@gmail.com> wrote: > That is funny for me because this is exactly the problem I am struggling > with now. > I store a lot of text (including headlines and lists) inside one info var > and retrieve it on another page. > '\n' sometimes translates to the paragraph tag, sometimes not. I could not > manage to identify a consistency. It is impossible to get all the > paragraphs right. > > Unfortunately people are forced to use paragraph tags because of > accessibility and general good practice. Margin styling of paragraphs in > css is common. Not using it would be a limitation for BoltWire. Starting a > paragraph with a dot would be a more serious limitation. > > I am sorry but I would vote for a more elegant solution for translating > textarea content into valid html. > > Greetings, Martin > Dan schrieb am Montag, 10. August 2020 um 23:24:19 UTC+2: > >> Hi all, >> >> From the beginning, I've attempted to create intuitive vertical spacing >> in BoltWire and have been reasonably successful. When you enter line breaks >> into your text, they show up in the html. And for the most part, wysiwyg... >> >> But it's never been perfect. Sometimes you have to fiddle with things a >> bit to get the exact vertical spacing you desire. Maybe add an extra <br> >> or use css to control the height of a table or div, or add some hardspaces >> to force a line break, etc. And the more you try and fine tune things the >> more you have to tweak other things to get it all to work together. It's >> not a huge issue, but it's one of those minor nuisances that keeps popping >> up now and then. >> >> Well, today I was trying to improve the brains in BoltWire to solve an >> irritating detail related to this, and ended up deconstructing the whole >> vertical spacing process and rebuilding it. Turns out there was a far >> easier way to manage things, and so far it's giving amazing results (both >> in the displayed output and in the underlying html). And while I may not >> have accounted for every possible markup or combination thereof, the code >> so far is working flawlessly--and producing beautiful, elegant code. And >> it's far simpler, meaning we could easily tweak things if I did miss >> something. >> >> There's one drawback however: I eliminated the <p> tag and switched to >> using a double <br> tag at the end of each line instead. I won't get into >> all the reasons, but essentially, forcibly inserting the <p> tag was the >> problem all along, because it was virtually impossible to tell when a line >> was a paragraph or something else--at least not in every case. And that >> ambiguity was really the root problem. Leading to complex code, and flawed >> output. Using line breaks just solves that issue. >> >> I went back through most of my main site and the display was pretty much >> identical. And wherever things were shifted one way or another, by editing >> the page, I found, it was caused by some jury-rigging fix that was no >> longer needed. Deleting those "tweaks", and everything fixed itself >> beautifully. In other words, the only problems were my complicated, time >> consuming, and hard to figure out, wonky, workarounds... :) >> >> Anyway, I'm inclined to put this new approach in the core. But wanted to >> solicit feedback on no longer wrapping paragraphs in <p></p>. In >> particular, I suspect this may cause some issues with html >> validation--though I'm not even 100% sure on that. And in every other way, >> it's just better. >> >> I recognize, in some cases there may be a need for p tags so I'm >> plannning to add some markup to manually indicate when a line of text >> should be wrapped in a paragraph tag. At the moment I'm thinking of a >> single "." at the beginning of a line of text would work nicely. It might >> require a change in your css so the paragraph vspace and the line break >> vspace don't double up in your output. But that's easy enough. >> >> On my site, I haven't found a single instance where the absence of <p> >> tag adversely affects the display, and the html is significantly more >> readable. But before fully committing, I wanted to invite feedback. >> >> Thoughts? >> Dan >> >> *Climb higher in your walk with God...* >> *WWW.FASTMISSIONS.COM <http://WWW.FASTMISSIONS.COM>* >> > -- > You received this message because you are subscribed to the Google Groups > "BoltWire" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to boltwire+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/boltwire/fae3439d-66b8-4c6f-8793-bc28de8f4f4fn%40googlegroups.com > <https://groups.google.com/d/msgid/boltwire/fae3439d-66b8-4c6f-8793-bc28de8f4f4fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To unsubscribe from this group and stop receiving emails from it, send an email to boltwire+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/boltwire/CABnVu_4zGCePFH-mP%3DzAG%2BpyPpAb-6tAgSfMAYE%3DnFRts7EK6Q%40mail.gmail.com.
