I just tried to import a post using the new option to do so using RSS. I hooked up my HEY World blog. When the post came over, some of the CSS was ignored, making the post look really weird. I ended up just having to delete it.
The post:
A standard post, for comparison:
Any ideas about what is going on here?
The imported post’s underlying HTML structure probably differs from your ordinary posts. But it would be easier to guess with an example to inspect. 
Thanks Sven. The original post is from my HEY World blog (which has really plain vanilla content structure).
I’ve deleted the post from my Micro.blog site, but it still shows up here (that’s another issue).
The problem is the original HEY World post; it’s not semantically marked up. For example, paragraphs are usually inside a <p> HTML element, but HEY wraps them in the generic <div> element instead. It’s not forbidden to do it this way, but a bit unusual.
The styling on your blog expects paragraphs to be inside <p> elements, so that is why you get the weird-looking presentation.
You could ask the HEY team to fix this or change your CSS to accommodate their markup.
P.S. The reason for HEY’s HTML looking like it does is probably because of their newsletter functionality. Email clients are picky about markup, and HEY probably shares the same HTML between email and web posts.
Ah, good catch. You also solved the mystery of why Pocket doesn’t parse those posts correctly. Thanks.
Just throwing my observation in here. HEY uses something called Trix Editor. They use it for Basecamp and, considering that fact, it comes with Ruby on Rails also (The framework they use to build their site/service - they also invented that framework). However, it doesn’t do normal markup as you’re used to.
My very own stuff that uses Rails also uses Trix and it suffers(?) from the same markup. It’s all inside DIV’s and “br” etc.
Yeah, it’s weird, Basecamp usually knows their stuff, but something went wrong here. It’s apparent in the project’s issue section.
Not providing semantic markup can pose accessibility problems in some situations. For example, when listening on a web page, skim reading by skipping paragraphs might be impossible when paragraphs are not marked up properly.
Also, a new paragraph is a clue to pause longer when reading a text out loud. Synthetic voices might not get that clue when <br> is used instead of <p>.
I’m sure, though, that there’s a good reason behind the decision. There are always compromises. Semantics and accessibility were not prioritized in this case.
