Why Do 3 Line Returns After a Paragraph in the Editor Equal 1 Blank Line After Each Paragrph in the HTML?

  1. I’ve written a multiple paragraph text document in the editor.

  2. When I select all the text in the document two previously hidden line return characters appear after each paragraph.

  3. When I use any of the Copy Special HTML menu choices the resulting HTML does not create empty lines between the paragraphs as shown in the editor.

  4. To fix this I need to hit the return key three times instead, which makes the text in the editor look too spaced out vertically.

Why do three blank lines after each paragraph equal one line in the html?

I have line spacing set to 1.0 and paragraph spacing has not been altered via the Format menu.

Just out of curiosity, what is the intended result you are looking for? Blank lines in HTML don’t do anything, so there is no difference between these examples:

[code]

one

two

one

two

[/code]

You refer to fixing this by adding two empty lines, but then that inserts a visual empty space in the output—a thing that is best done by using styled space, not by inserting a faux paragraph with a break in it to force the issue. For example:

[code]

one

two

[/code]

I’ve simplified the example for legibility, but the above is essentially the route Scrivener takes when using paragraph spacing as a model for introducing gaps in the text.

To answer your question simply though, it is that way because some writers double-space their paragraphs without the intention of it being a space, but simply as a preference or necessity (those using Markdown-based writing methods for example). The way it works currently accommodates both writing styles, and meanwhile uses the preferred method for adding vertical space in a document, CSS.

Yes, I realize that , based upon my prior years of experience.

I am interested in using Scrivener to store Blogger posts. I want to copy individual posts from Scrivener and past them into Blogger as needed. The appearance of all posts on Blogger is already administered by a custom xhtml template thus I do not want Scrivener adding any inline formatting or CSS style sheets. I only want Scrivener to export my text with standard html tags.

I have used a product for eBay sales for many years which has a similar GUI to Scrivener called GarageSale. I could see possibly adopting a second copy of this program to store my Blogger snippets, but wanted to check out alternatives first.

iwascoding.com/GarageSale/

I am looking to better control the way Scrivener is formatting its HTML.

When I type the following three paragraphs with two line returns after each paragraph…

Scrivener should format the HTML as…

[code]Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.[/code]

In the editor it shows two line returns between each paragraph:

Using Edit > Copy Special > Copy as HTML (Basic, using
) produces the output:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.

In order to get the desired HTML output I need to enter the text with three line returns:

Which inserts the desired number of tags, but which also produces sloppy html with unwanted blank lines.

[code]Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.


Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.[/code]

As I don’t need to edit the raw html it really should be exported as:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.<br><br>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus. <br><br>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque aliquam ut risus nec congue. Mauris at ipsum semper, gravida nunc sed, lacinia lectus.

I didn’t see anything in the custom toolbar settings for a HTML Copy button. It would be nice to have three optional buttons in the Toolbar which would copy a document’s text as one of three HTML formats with just one click. This would save a great deal of time in that the text would not need to selected first and a menu would not need to be navigated.

Okay, that’s fine and good. I wasn’t sure if you were trying to insert an exceptional space here and there (like a scene break) or what. But you’re talking about every single paragraph?

Is that really what Blogger recommends separating paragraphs with? The line break[size=80][1][/size] isn’t meant to be used for paragraphs—we don’t make that option available for what you’re using it for in the first place, we make it available for those copying verse and such. Marking paragraphs with opening and closing p elements is far more flexible, expected and should be styled correctly for decades to come.

I mean, do what you want do of course, but I just thought you might want to know that what you’re doing is a bit like using an h3 tag instead of h1 because you like the font size better. The idea is to change the font size of h1 with CSS, not use a semantically incorrect outline heading to force it. It’s not invalid or anything, you won’t break the site, it’s just not best practice.

As I said in the prior message, it already works the way it should. It is designed to work this way to accommodate two different writing styles. I type in paragraphs the way you do, but for entirely different reasons. Here is what typical a before & after looks like for me:

[size=80][/size]

As it stands, both approaches produce the same output right now, which is what is intended for the feature. Both methods also produce valid and correct output by default. If you add additional newlines in the document to force extra-stylesheet spacing that’s up to you, but we didn’t really design this system with the thought in mind that it would be used to implement paragraph spacing. It’s for stuff, like I said earlier, like scene breaks; special cases.

If we added a button for everything requested over the years the toolbar customisation palette would be as massive as the main menu system, and we’d have a similarly massive budget for icon designs. :slight_smile:

Adding your own keyboard shortcuts, as described in the user manual under Appendix A.1, is the best way to make commonly used menu commands more accessible. If you do this all the time, try putting F3 or something on the command.

[size=120]Notes[/size]

[size=80][1] Under Tips and Notes: “Note: Use the
tag to enter line breaks, not to separate paragraphs.” This element is meant to be used for exceptional circumstances, such as printing addresses, lines of verse, formatting a subtitle line, etc.[/size]

Blogger’s editor inserts
tags for line breaks.

The
line-height is automatically determined by various font related CSS within the XHTML template.

Hopefully Google knows what they are doing ;0)

Well, sometimes they do, but I’ve seen some pretty awful stuff as well. :slight_smile: My guess is they are doing things that way as a sort of compromise between WYSIWYG use and end result. I think even Google would agree it is not best practices, but they’d perhaps get complaints if someone added five empty lines and they all collapsed to none.

In fact, this forum even does that with the post material you type in. All carriage returns are converted to breaks instead of attempting to parse for paragraphs. It means I can do this…

So they have no CSS for handling the more traditional

element approach? I do note in the screenshot there appears to be an option for doing things a different way. I don’t know what “Press ‘Enter’ for line breaks” means though, that’s a bit cryptic.

That’s for how you wish to edit your posts…

egtutorial.com/blogger/intro … -settings/

The height of the paragraphs would be determined by the font’s CSS attributes such as line-height. As Blogger’s newer templates are mobile ready there are a series of CSS media queries in the XHTML template that further modify the default font CSS attributes based upon the screen width of a device,

I’ve added about 150 lines of custom CSS to one of Blogger’s default mobile ready templates and altered 50-60 more lines to obtain the appearance and functionality I want for my brand. The page source for a recent test post consisting of 666 words and several images included 88
tags while the only

tag was within the header’s site description under the header’s site title. One is free to add CSS for all or targeted

tags as needed.

I’ve added a custom Keyboard Shortcut (Shift+Command+C) for the menu item “Copy as HTML (Basic, using
)”.

This leaves the dilemma of the two main competing ways I wish to export text from the edit window.

  1. Paragraph + Two line returns:

A. Copy the text to another App such as TextEdit will be correct.
B. Copy as HTML (using
) will be incorrect (only one
tag inserted),

  1. Paragraph + Three line returns:

A. Copy that text to another App such as TextEdit will be incorrect due to extra line-returns between paragraphs.
B. Copy as HTML (using
) will be correct (two
tags inserted),

This could be solved by adding a simple preference for the menu item “Copy Special > Copy as HTML (Basic, using
)”. This preference would be turned off by default so it would not interfere with any current users, but add a additional market sector of users.

For example - a checkbox to ignore the default HTML rendering. A single
tag would be inserted for each hidden line-return in the editor as opposed to the current rendering engine which causes the number of
tags to be one less than the number hidden line-returns shown in the editor. That would allow to type and paste text in the same format I’ve been using since the late 1990s while still obtaining HTML text with the correct number of lines

We’ll consider it. We do hesitate to add preferences since, well you might have noticed we already have a few. :wink:

Meanwhile this is exactly the sort of thing I would build a paste filter for, using my typical suite of automation tools. In my case that would mean a Keyboard Maestro macro that:

  1. Triggers the Edit ▸ Copy Special ▸ Copy as HTML (Basic, using
    )
    menu command.
  2. Runs a simple search and replace on the pasteboard, dupicating the effect of all elements found on a line by themselves.
  3. Injects the updated string back into the system pasteboard.

I could even go further and have it switch to the browser, focus the composition text field and paste. Automator or other tools may be able to do something similar. Speaking of which I’m now going to use something quite along those lines to post this response now!