Revert #767

[dyve]

This reverts commit b49879ced1a411f82ea07d8c2a64727f49c77c64.

[coveralls]

Pull Request Test Coverage Report for Build 18629441071

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.917%

---

Totals
Change from base Build 18628381151:	0.0%
Covered Lines:	1433
Relevant Lines:	1454

---

💛 - Coveralls

[dyve]

Apparently there is no agreement on how to resolve #763 and possibly #749. We may have to revert #767.

[xi]

As I see it, there are two points of disagreement:

• Bootstrap only shows the error messages when they come after an invalid input. It uses the ~ selector for that, which is brittle and has resulted in issues in the past, especially with complex widgets that may contain more than a single input element (#763, #749, https://github.com/zostera/django-bootstrap4/issues/124). My impression is that bootstrap's logic is geared towards client-side validation, while django-bootstrap5 is geared towards server-side validation. I therefore proposed to add a d-block as a robust solution for all of these cases. Others think that this is unnecessary.

• If there are multiple error messages, should the invalid-feedback class be on the individual errors or the wrapper?

  • We need a wrapper with the id {{ field.auto_id }}_error for django to refer to in aria-describedby.
  • If we decide against d-block in the previous point, we need the class on the wrapper so it shows up.
  • Visually, there is a small difference in the margins between these two versions (see https://github.com/zostera/django-bootstrap5/issues/763#issuecomment-3258551606).

Either way, we all agreed that this is an issue. I honestly care more about a quick fix than any of these details. I propose to cut a release soon and refine later.

[dyve]

Either way, we all agreed that this is an issue. I honestly care more about a quick fix than any of these details. I propose to cut a release soon and refine later.

I agree. With the understanding that we may revert #767 if we have consensus / consent for another solution, let's first make sure we have a working solution as part of the next release.