Ode to the Non-Breaking Space
It should have been a simple thing to do:
Type ampersand, then N and B S P —
A semicolon seals the deal: — but no!
That entity is lost (it's "disappeared") when switching tabs
As if an unseen hand has swept it all away.
I picture it: "Let's make it 'easy,'"
thought the Devs. "We know that poets can't write code,
So let's just duplicate a <pre> and call it 'Verse'
We'll coax them (force them) to the hated block, at last."
It's clear, from that, they knew there was a need.
But why not just retain the entity
From Classic tab-to-tab already there?
And so, I cracked the block
And saw the <pre> not knowing whether I
Should groan... Or laugh.
So doing both, at last, I modified the CSS
(Like desktop publishers of old)
Triumphant, "disappeared" their relic Courier font
In favor of my own.
It really shouldn't be this hard, you know?
Today’s Poets
Not all code is poetry, that’s for sure. Today’s poem was born out of yesterday’s frustration. There is an 11+ year old bug in WordPress – oft complained of but never solved, wherein HTML code entered in the Classic Editor’s Text tab is wiped away on switching to the Visual tab. Not all HTML code, else the Text tab would have no reason for being, at all. But simple little things like non-breaking spaces at the front of a line, as used by poets, sometimes. Or in code! Oh, yes, there is a “code block” or tag – there’s the <pre> tag. But that, by default, formats text in Courier – not in the post’s default font. “Use the block editor and insert the Verse block!” is a solution, apparently – but you know what that is? Verse is simply <pre> styled with a class=”wp-verse-block”. And I suppose one could use the block editor, insert Verse block, and manually style the damned thing.
Or do what I finally ended up doing, once I “peeked under the hood” and saw that Verse was just <pre> – add CSS to style <pre class=”poem”> or <pre class=”wp-verse-block”> (I did the former, since the latter takes longer to type) and have done with it – because unlike standard HTML entity codes for non-breaking spaces and such, a <pre> tag doesn’t get stripped out when switching from Text tab to Visual tab.
WordPress devs, why you gotta make this so hard? And why have you ignored the issue – brought up often enough in Support and in GitHub and elsewhere – for over 11 years? How hard can it possibly be to render standard HTML?
No, not all code is poetry. But in honor of the cross-over genre of “Code poetry – Wikipedia,” today’s featured poets are not drawn from an alphabetically-ordered list. I wonder if there’s any poetry to be found in a sort routine?
School for Poetic Computation – Wikipedia
April is National Poetry Month. This year marks its 27th year. NaPoWriMo – 30 days of writing poems – is poets’ answer to National Novel Writing Month (NaNoWriMo).
This coincides with the A to Z Blogging Challenge, now celebrating its 13th anniversary. Some participants choose a theme; others wing it. Doesn’t matter! The real challenge is to build a practice of writing daily. I think I stuck with it…once. There’s still time to sign up – registration ends April 9. You can see the list of participants – I’m sure they’d love it if you’d visit and comment on their blogs.
This month, my goal is to:
- Write a poem a day and share it – uncurated – here; and
- Highlight some poets you may be unfamiliar with.
I encourage you to click the links to read about them and their work. I plan to choose a diverse array of classical and contemporary poets – indigenous poets, Black poets, women poets, LGBTQ poets – that challenge us to see the world differently while also tapping into universal themes and emotions.
Remember, too, that comments and conversation are always welcome here. (Spammers, on the other hand, will be tossed into the moat or mocked, so before you leave an irrelevant comment or drop a link, consider that it’s fair game!)
I’ve never tried using HTML codes that WP hasn’t given us, though some of the newer themes are way more advanced in their CSS coding. It’s only by changing some CSS coding in the theme that’s allowed me to change font colors when I want something specifically highlighted in an article. I tried coding it that way initially, but it wouldn’t take because CSS wasn’t set up to deal with it. I guess that’s why we are who we are… whatever that means. lol
Yep. I get that they are creating jobs for independent WordPress developers, but you and I are DIYers when it comes to our blogs AND we have no aspirations to BE WordPress devs – we just want to be able to get under the hood and do the things we’ve done for decades, without having to jump through hoops. We’re too advanced to settle for out-of-the-box generic templates (those are never a good fit, unaltered, for our personalities), but we don’t want to have to learn how to code a whole theme, either. I guess we’re outliers, Mitch. I was seriously down to “I’ll just go back to an all HTML website I can code by hand in Notepad and f*** all y’all… 😀
This brings back memories of my (brief!) foray into the WordPress Loop. This was before the days of block editors and page builders. It really is more like programming than writing, so I feel your pain. I hope the poem was cathartic! LOL
Cheers,
Mitch
Yes, and just about the time I started to understand “the loop,” they started introducing “blocks.” I swear, the more programmers try to make things so simple a five year old can do a thing, they end up making it HARDER to accomplish anything at all.
Remember when computers were supposed to automate the tedious tasks and save us precious time? Hah.
I refuse to use Blocks; didn’t have time for a learning curve. Luckily, there’s a plugin for that. lol
Won’t fix this problem.
We have had to use so many times over the years, sometimes a series of them to stand in for paragraph indents, and noticed the same behaviour. I have had to ask my team to enter their work in text mode, and this is one of the chief reasons. On some of our sites, we now have adopted a stylesheet definition to get the indent because of Wordpress’s limitations. Plus they are absolutely vital: what if you were setting in French, which prescribes a full, non-breaking space before a colon?
Having said that, it seems non-breaking spaces, these days, break. It’s really annoying. As a result, when setting in French, we now have to put in <nobr> codes as well as . Most French folks now follow the Anglo convention but we prefer to be correct!
I don’t mind flipping tabs, but I very much mind WordPress stripping out my HTML codes when I do! Ugh. You can write a style guide that says “never, ever, ever edit on the Visual tab, and never ever SWITCH to it, even for half a second, because you’ll eff up EVERYTHING” but that’s risky. Thuse my workaround, here. You could maybe just wrap everything in a <pre class=”something”> and then you’re fine. Now, I should add that there’s this weird behavior that can STILL bite you in the butt – if you edit inside the <pre></pre>, on the Visual tab, you may find it trying to add new <pre> tags. I’m not sure that it closes them properly. I saw that and just got really careful about not doing it – it’s still better than the default, but does also tend to mess up line breaks.
I’m glad YOU get it. I just feel gaslighted, you know?
Ironically, to get those tags to display in COMMENTS, I had to use the HTML entity codes. And they stick.
And WHERE are the French WordPress devs, Jack? Why aren’t they screaming about this??
Me, too. I knew they would not render properly without the codes. And I wish the French would do something! It’s not just Wordpress, but HTML. We have to add   as well with other punctuation, and the <nobr> tags! If you ever see French articles on the Lucire website, they are always a few kbyte larger. Takes ages to add everything, too!
Yep, I can always tell when a team member has edited what I deemed to be the final version as they occasionally flip between the tabs. Gives them away every time because the spaces all disappear!
Well… I learned the hard way, back in the mid-1990s. Got a French translation of a Windows Help file that I’d developed in English and spent hours taking all the spaces out from before terminal punctuation. <facepalm>
That was embarrassing. Fortunately, I still had the original translation and could revert. But… yeah. You can imagine the conversation with the translator.
In those days, how did you make sure that the punctuation didn’t break on to the next line? Was it just very careful (on-screen) typesetting?
In those days, we used Microsoft Word. Plus a good search/replace for space-punctuation to non-breaking-space-punctuation.
That makes sense. A non-breaking space didn’t break in Word, unlike HTML!