Improving consistency and accessibility between TabularInline and StackedInline.

[Antoliny0919]

The biggest difference between TabularInline and StackedInline is the direction in which the fields are arranged(row or column).

Currently, TabularInline and StackedInline seem to clearly showcase their differences.
However, I don’t think there should be any difference regarding the __str__ of the Form objects inside TabularInline and StackedInline.

As shown in the image above, TabularInline only displays the object’s __str__, while StackedInline adds the model name and a colon as a prefix to the object’s __str__. (Additionally, the font size in TabularInline is very small, and there is a noticeable font size difference compared to StackedInline. Furthermore, the font size of the fields also changes when the screen resize.)

As mentioned above, TabularInline and StackedInline already effectively represent their unique characteristics through the arrangement of fields, so I don’t understand the difference in the object(str) related parts. I believe these should be made uniform to improve consistency between the Inlines.

Additionally, when the show_change_link attribute is set to True to add a link in the inline, the background image in TabularInline gets slightly cut off at the bottom.

I think it would be better if the show_change_link attribute were set to True by default. Also, when the show_change_link attribute is set to True, I feel that the background image and text(Change or View) that appear are unnecessary. This is because the form already effectively represents these characteristics.

I have applied the link to the object’s __str__ as shown in the example above. However, when making changes like this, additional handling may be needed if the __str__ is empty or contains something like “-”.

To summarize the points so far, I believe there needs to be consistency in the object __str__ section for TabularInline and StackedInline. By setting the default value of the show_change_link attribute to True and making the link more streamlined, accessibility can be improved, and it will look cleaner as well.

I have already created an issue regarding this and feel that further discussion is needed.
(I would appreciate feedback or thoughts from others on these proposed changes.)

Issue

• Cleanup the inline link format.
• Size of the object’s str in TabularInline is too small

[Antoliny0919]

I have implemented the improvements I had in mind into the InlineForm
InlineForm header new feature.

In addition, further steps are needed, such as adjusting the position of the “x” button and handling cases where the string used as a link is empty.
Still, I believe the changes above are enough to show the InlineForm header as I envision it.

I can relate to many aspects of why the current Inline design was implemented.
I had wondered why the text of the object’s str used in the Form Header of TabularInline is small.

However, since TabularInline represents fields in rows, the height of the Form within TabularInline is not large, so there’s no need for the object’s str text to be large.
(Nevertheless, I still feel that the current text size is too small.)

On the other hand, StackedInline represents fields in columns, and as the number of fields increases, the height of each Form grows as well.
In this case, the object’s str serves as a separator between the Forms.
Therefore, I understand that the object’s str is displayed larger and that the model name was added to the suffix.

The reason I made the TabularInline header the same as the StackedInline header is because I felt that the StackedInline header provides better UX
(of course, adjustments to the font size and padding are needed).

This is because, just like in StackedInline, the height of the page in TabularInline also increases as the number of objects grows. Ultimately, whether it’s TabularInline or StackedInline, I believe the current StackedInline header is better when there are many objects.

However, the StackedInline header doesn’t feel out of place when there are fewer objects either.

The reason I added a link to the object string itself is that I thought this approach was much cleaner. I felt that there was no need to display text like “View” or “Change” — adding a link directly to the string itself is intuitive enough.
(However, it is important to clearly distinguish it from the “View on Site” link that appears when the show_url attribute is True.)

I’m curious to know what others think about the InlineForm Header. I’d love to discuss it more and I feel there is room for improvement.

[CodenameTim]

Generally speaking, as another Django dev, I really like seeing these changes. I’ve run into your original concerns about labels missing or being inconsistent and I never understood why it felt “off”. Now it makes sense.