I took a quick look at blurt, the new WordPress short-form blogging theme available on WordPress.com.

It's a theme, just like Baseline is a theme. Themes can alter the behavior of WordPress in almost any way imaginable. It's still just a theme, so if Blurt is not using too much WordPress.com magic, it should be able to used on a self-hosted site.

The artificial 500-character limit is clunky. The compose box simply is disabled if there are too many characters. If you edit the post in the WordPress dashboard, when saved extra characters are silently dropped.

With WordLand I can post 600 characters, and they don't get cut off. If I try to edit that, the save fails. It's an early version, Blurt doesn't know how to handle posts coming from outside its UI.

I'm not sure why everyone thinks a character limit is a defining feature of social media. That should be up to the writer, not the platform. It should be a threshold, not a wall. micro.blog seems to handle this well (at 300 characters the UI show a title field you may choose to use or not).

All in all, it's a cute idea, and I look forward to see how it develops. (Sorry for the fart joke title.) (Actually I'm not sorry. 😃)

It's been a while since we checked in here, so here's what's going on with the Baseline theme.

• v0.2.3 adds support for WordLand linkblogs. For posts in the 'linkblog' category, the link URL will be rendered as a link at the end of the post. A date headline appears above the posts for that day. The customizer includes an option to use the linkblog layout for the home page, for sites that consist entirely of linkblog posts. See https://links.daveverse.org for an example.
• v0.2.4 adds support for the feedland-blogroll plugin. If the plugin is installed, the home page will be rendered in two columns with the blogroll in the right column. See https://daveverse.org for an example.
• The RSS Cloud plugin for WordPress hasn't been updated in a while and wasn't working as expected. I wrote a simple RSSCloud External Ping plugin to add the cloud element to the RSS feed and ping rpc.rsscloud.io on new and updated posts. If it keeps working well I'll submit it to the wordpress.org plugin directory.

Upcoming changes will include:

• Now we create an artificial title for titleless posts. That is suboptimal when there are a lot of titleless posts. We need to offer an option to suppress the artificial titles, and perhaps show date headlines (like for linkblogs) instead. 
• The now theme has so many options it is becoming unwieldy to develop. We need to break it down so the options (linkblogs, blogrolls, etc.) are plugins or separate themes in order to streamline the basic Baseline theme.

I've published a minor update v0.1.5 to the Baseline theme. It now shows a minimum number of posts on the home page, even if you haven't written any posts in the past two months.

Now that linkblogs have been added as a feature to WordLand, we're thinking about how best to display them with the Baseline theme. I've put up a prototype of a linkblog in WordPress to experiment with the layout. (The prototype gets it's data by polling the RSS feed once an hour rather than from WordLand, but the basic idea is the same.)

It's nice to have the baseline around, because now I have something to match the presentation of H3's with. The next version of WordLand will have that worked out.

Had to back out of the Styles panel of the Settings command, I did it way too fast, each feature it added had to be tested in this very particular context.

The context is Medium Editor, Markdown and WordPress. None of which were designed to work with each other. We're lucky to have a core subset that works, enough to support writers.

I think to get a really complete editor, you have to start with Markdown or HTML and work it out with WordPress.

I have made the style of H3 agree with the style of in the Baseline theme.

Scott, a discussion on the support repo about whether we should have H4 in the popup menu led me to consider an option I had been thinking about in the background — letting the user configure the contents of that menu. It's basically a list of names, chosen from these:

bold, italic, underline, anchor, h1, h2, h3, quote, unorderedlist, orderedlist, pre, removeFormat, justifyLeft, justifyCenter, justifyRight, justifyFull, indent, outdent

They all seem to work. Special provisions need to be made in the baseline site for h1, h2, and h3, esp h3.

h3 should be the same font-size and line-height as a paragraph, but boldface. 

It's the best way to add a headline to writing in wordland. Imho any other size starts getting into MySpace territory.

For Change #5, I once again used an add_filter function to replace the HTML generated by WordPress, this time for the next/prev links. The links show only an arrow at 1.5em (24 px), no underline, with the post title in the title attribute of the anchor tag so it shows up as a tool tip.

For Change #10, since we can include PHP code in the theme, we don't need to use JavaScript to filter out the Uncategorized category. We can use an add_filter function on the get_the_terms hook in functions.php to remove Uncategorized before the wp:post-terms block displays the categories.

The block also has a parameter for the prefix to the displayed list, so we changed it from "Posted in " to "Categories: ".

I thought Change #11 would be simple. The icons are in a social-links block, and an RSS feed is among the supported services.

However, adding

<!-- wp:social-link {"url":"#","service":"rss"} /--> 

to the sidebar failed. I had to dig into the WordPress code itself to find the service is named "feed", not "rss". The correct syntax for the RSS feed icon is

<!-- wp:social-link {"url":"#","service":"feed"} /-->.

🙄

Hooking up the correct link to the icon is a task for later.

Update: We put an add_filter function in functions.php to put the actual feed link on the icon (Commit 38b1a45).

For Change #4 some adjustments to the post body text were requested.

• Font size should be 18px
• Font weight should be 400
• Font color black on white background
• Values should be able to be changed in browser dev tools

In block style WordPress themes most of the CSS is in the theme.json file.

• The font size in a post is set in core WordPress to the CSS variable –wp–preset–font-size–normal. "normal" is set in WordPress itself to 16px, so I set "normal" in theme.json to 18px.
• I also increased the "small" font size from 16px to 18px. 
• Under "typography" I changed the font weight from 300 to 400.
• Also under "typography" the background was already set to white, so I left it.
• Yesterday I posted on how to view and change CSS variables in dev tools.  
• On my own, I also increased the size of "x-small" text from 14px to 16px, since the text in the sidebar and the footer seemed too small compared to the 18px post body text.

Once these changes are tested, they will become version 0.0.2 of the theme.

In the list of change requests, regarding font sizes Dave asked: “Also if you can make it so those values can be changed in the browser. The way they have it set up, I can’t play with via the debugger, and that’s much faster than going back and forth in the editor.”

The font sizes in the base Retrospect theme are set using CSS variables. I’ve never worked with CSS variables before, so I asked my friend ChatGPT 4o: “In the Chrome dev tools, I am viewing a site where the font-size is set with a css variable. How can I try out a new font-size in the dev tools?”

ChatGPT answered:

---

Nice — Chrome DevTools is great for this kind of experimentation! If the font-size is set using a CSS variable, you can easily test a new value by overriding that variable or applying a direct style.

Here are your options:

---

✅ Option 1: Override the CSS variable in DevTools

Example situation:

The element has this style:

font-size: var(--wp--preset--font-size--small);

To test a new size:

1. Open Chrome DevTools (Right-click > Inspect).
2. Find the element in the Elements panel.
3. In the Styles pane on the right, find the rule that uses the variable.
4. Right below it, add a new line and override the variable:

--wp--preset--font-size--small: 24px;

You’re directly changing the variable value — everything using it will update.

🔁 If multiple elements use that variable, they’ll all reflect your test size immediately.

---

✅ Option 2: Add a temporary inline override

If you just want to test the result on a single element without affecting others:

1. In the same Styles panel, add:

font-size: 24px !important;

This overrides the variable usage completely.

---

✅ Option 3: Modify the variable on the :root or body

Some variables are defined globally on the :root or body element. You can go to the Styles pane for html or body, find the declaration like:

:root {
  --wp--preset--font-size--small: 16px;
}

And change it there to:

--wp--preset--font-size--small: 24px;

That updates the variable site-wide — great for testing global changes.

---

🎯 Pro Tip: See the resolved size

If you hover over the computed font-size in DevTools, Chrome will show you:

• The computed pixel value
• The source CSS variable