1. I selected A1:B3
2. I set them to Bold
3. I inserted rows below (so they pushed the bold ones down)

All of the new rows had Bold in the first two cells as expected.

If I should use some other steps, please give them in a more clear way.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: d73225119476de1826f648acca9e93bf6797e813
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 12th 2017

Try the following: type something into cells in row3
type something into cells in row4
Now change the attributes of the cells in row3

Copy the cells to new rows (e.g. to rows7 and 8)

Now, select a cell in row 3
Add a row below row3 using the toolbar button.
Type text into the cells in the inserted row. 
The cells have inherited attributes from the row above it.

Now select a cell in row9 (remember that rows 7,8 moved down one because of the insert row done above.
Now add a row above row9
The cells inherit attributes from row8, not from row10

Does that make sense?

Why is this a problem? If I have total row at the top, I would change the background, borders or font to show it is a total line.
Then type my detailed list below that.

Now, if I want to add a detail row to the top of the list (i.e. insert a row between the total row and the first detail line) it will always inherit the attributes of the total line.

Note:when I create a sum range, then it acts as I suggest. 
e.g. cell c13 has sum(c14:c20)
If I select C13 and add row below, it adds the row and C14 inherits the attributes from C13. The formula remains as SUM(C14:C20)

If I undo all of this, then select C14 and add a row above it, the attributes are inherited from C13, but the formula in C13 has changed to SUM(C14:C21), which is good.

Apologies I just checked that and I was wrong. 

The SUM does not change as I thought, but I hope you understand what I was driving at.

(In reply to Elmar from comment #2)
> Try the following: type something into cells in row3
> type something into cells in row4
> Now change the attributes of the cells in row3
> 
> Copy the cells to new rows (e.g. to rows7 and 8)
> 
> Now, select a cell in row 3
> Add a row below row3 using the toolbar button.
> Type text into the cells in the inserted row. 
> The cells have inherited attributes from the row above it.
> 
> Now select a cell in row9 (remember that rows 7,8 moved down one because of
> the insert row done above.
> Now add a row above row9
> The cells inherit attributes from row8, not from row10
> 
> Does that make sense?

Yes, I get it now. It does feel illogical.

Created attachment 137781 [details]
Example file

File where one is ready to insert rows and observe the effects.

Created attachment 138780 [details]
test document

Added document to describe the inappropriate behavior when inserting rows and columns

Created attachment 138781 [details]
shows results after insert

See the steps inside the doc.

Please see the new document examples that I have attached.

The one you posted shows what is currently happening which is what I am complaining about.

Created attachment 184457 [details]
spreadsheet with standardised formatting etc.

consider sheet "Styles"

Select cell M27 

insert row above. I would expect to copy the formatting from the selected row.
The way Calc works is that it always inherits the formatting from the row above the newly added row.

In the case of adding a column to the left, Calc always inherits the formatting to the row to the left of the added row.   

Des this make more sense?

You may view this as an enhancement, and not a bug.
If so, you're the boss.
In which case you may close the bug.

This is in the documentation:

Working with columns and rows
Inserting columns and rows
When you insert columns or rows, the cells take the formatting of the corresponding cells in the column to the left or the row above.

https://books.libreoffice.org/en/CG75/CG7501-Introduction.html

So, I will close this bug as works for me.

I do not understand the logic.
If I am going to base a decision on what the user guide says, then I can simply change the user guide to fit my decision.
What does the standard say?
If it does not address this who arbitrates?
But, I see that this does not have the support of anyone else, so after a last attempt to change your (development team) collective mind, I will let it go after one last attempt at improving usability.

Why permit add row above / left if the attributes are only going to be assumed from above or to the left? If I add a row above, it means I want the row above it to have the same attributes. Ditto add left.

It is like offering a child and ice cream of any flavour and then telling them that they can only have strawberry.

(In reply to Elmar from comment #0)
> Description:
> When adding a row or column (or cell), added cells always assume attributes
> from the row above (or the left). 
> Instead, logically, the attributes should be assumed from the selected
> cell(s).

The request is at least worth of consideration.

IDK how other spreadsheet tools are nowadays behaving regarding the formatting of the newly-inserted row (above/below). This is relevant for users, considering that inserting a row (above or below) is a very common action in any-and-all spreadsheet tools.

I am changing this report to ENHANCEMENT (request, instead of being considered as a bug/failure).

Let's ask UX what they think about modifying (or not) the current behavior. If it gets modified, this should be clearly announced (e.g. release notes), preferable at the start of a new (major) version (as opposed to changing it in the middle of a cycle).

Note that inserting rows/cols below/right copying attributes from above/left was the original functionality and that is what is documented. Inserting above/left was added later somewhen and implemented internally by just changing the reference point and keeping all existing logic, e.g. on row 2 inserting a row above behaves like on row 1 inserting a row below.

I consider changing the behaviour a valid request, but also bear in mind that when inserting above a "table with header row" one quite likely does _not_ want the attribution of the header row being copied.

I guess left is also not right aka prior in case of RTL.

We discussed the request in the design meeting. Of course, adding before/above should duplicate the formatting similarly to after/below. Easy hackable, Hossein?

(In reply to Eike Rathke from comment #18)
> bear in mind that when inserting above a "table with header row" ...
Don't get this. If a range has an autoformat/table style it should update properly.

(In reply to Heiko Tietze from comment #20)
> (In reply to Eike Rathke from comment #18)
> > bear in mind that when inserting above a "table with header row" ...
> Don't get this. If a range has an autoformat/table style it should update
> properly.
I wasn't talking of autoformat, just generally that if one inserts above a row that has cells formatted like column headers (i.e. bold or a different cell background colour than data below), one likely does not want the newly inserted row(s) to have these header attributions as well. Same for inserting left of a column with row headers.

(In reply to Eike Rathke from comment #21)
> ...just generally that if one inserts above a row that has cells formatted
It's wrong either way- but easier to clean up the formatting.

(In reply to Elmar from comment #0)
> always assume attributes from the row above (or the left). 

Not always.
See animated .gif at https://ask.libreoffice.org/t/why-does-calc-insert-formatting-randomly/53965/10?u=leroyg


Rows:
1. If you insert a row above it will get the styles applied on the above row.
2. If you insert a row below it will get the styles applied on the actual row.
3. If you insert a row below or above the row 1 it will get the styles applied on row 1.
(https://ask.libreoffice.org/t/when-i-insert-a-row-into-calc-the-font-for-the-row-is-not-the-default-for-the-sheet/59931/4?u=leroyg)

Case 3 (when row above) is an exception.


Columns:
1. If you insert a column to the left it will get the styles applied on the left column.
2. If you insert a column to the right it will get the styles applied on the actual column.
3. If you insert a column to the right of column 1 it will get the styles applied on column 1.
4. If you insert a column to the left of column 1 it will get the default style.

Case 4 may be as expected, but it is no consistent with case 3 for rows.

Version: 7.4.3.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 1; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: es-MX (en_US.UTF-8); UI: en-US
Calc: threaded

*** Bug 108016 has been marked as a duplicate of this bug. ***

*** Bug 144007 has been marked as a duplicate of this bug. ***

*** Bug 154327 has been marked as a duplicate of this bug. ***

Just add a small note that IMO this is not a good candidate for an EasyHack. Also, I think MS Excel compatibility is important here.

*** Bug 161384 has been marked as a duplicate of this bug. ***

*** Bug 163929 has been marked as a duplicate of this bug. ***