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

1. I want to be able to edit all the categories for a site in a single list. The idea of doing it piecemeal is not good. On the other hand the editor they have on the WordPress side is pretty easy and quick. But I think having a list in the writing environment is even better and I need/love and use categories these days, which is a good habit I want to keep developing. 

2. I want to be able to paste an image in the way it works on GitHub. What a pain in the ass to have to save it to a local file just so I can upload it.