Skip to content

Conversation

@xi
Copy link
Contributor

@xi xi commented Sep 3, 2025

Fixes #763 and potentially #749

I also fixed the .input-group related issue I mentioned in #763 (comment).

I implemented this as an alternative to #766 because I thought that just overwriting bootstrap's display: none is more robust than adding dummy elements.

xi added 2 commits September 3, 2025 16:10
Bootstrap sets `display: none` unless the error comes after an invalid
field.

Fixes zostera#763 and potentially zostera#749
@coveralls
Copy link

coveralls commented Sep 3, 2025

Pull Request Test Coverage Report for Build 18627842736

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 Coverage Status
Change from base Build 18627808431: 0.0%
Covered Lines: 1433
Relevant Lines: 1454

💛 - Coveralls

@ppfeufer
Copy link

ppfeufer commented Sep 5, 2025

This would be the correct HTML:

{% if field_errors %}
    <div id="{{ field.auto_id }}_error" class="invalid-feedback">
        {% for text in field_errors %}
            <div>{{ text }}</div>
        {% endfor %}
    </div>
{% endif %}

As Bootstrap targets the directly followed element of .is-invalid via CSS via the ~ selector, here .is-invalid~.invalid-feedback:

.is-invalid~.invalid-feedback, .is-invalid~.invalid-tooltip, .was-validated :invalid~.invalid-feedback, .was-validated :invalid~.invalid-tooltip {
    display: block;
}
image image

No need to "manually" add the display or width classes.

Credit goes to @christianwgd in #763 (comment)

@xi
Copy link
Contributor Author

xi commented Sep 5, 2025

That would not fix #749, would it?

@ppfeufer
Copy link

ppfeufer commented Sep 5, 2025

It should, since it's the same markup required and as long as the template is injected at the right place.
I don't have a form with these kinds of fields, but I don't see a reason why it shouldn't fix this.

@ppfeufer
Copy link

ppfeufer commented Sep 5, 2025

If it has worked before, then it should work now.
The only difference is that - now - the wrapper needs the class, not the error message div itself.

@ppfeufer
Copy link

ppfeufer commented Sep 5, 2025

It definitely works with multiple fields …

image

ppfeufer added a commit to terra-nanotech/tn-nt-auth-templates that referenced this pull request Sep 5, 2025
## [3.12.0] - 2025-09-05

### Added

- Workaround for `structuretimers` form template to use Bootstrap5 form until fixed
  and release upstream (https://gitlab.com/ErikKalkoken/aa-structuretimers/-/merge_requests/22)
- Workaround for `django-bootstrap5` error template until it is fixed and released
  upstream (zostera/django-bootstrap5#767)
- Bottom margin to DataTable filter wrappers
- Bootstrap tooltips to `package_monitor` templates
- Transition animation to overflow changes
- Overflow detection and monitoring
- Border radius to active menu items

### Fixed

- HighlightJS copy code button size and position
- Some transparencies
@dyve dyve changed the title make sure that field errors are always visible Make sure that field errors are always visible Oct 19, 2025
@dyve dyve merged commit b49879c into zostera:main Oct 19, 2025
26 checks passed
@ppfeufer
Copy link

ppfeufer commented Oct 19, 2025

You just merged the wrong markup.
The .invalid-feedback class is on the wrong div here, see comments above and the discussion here and following …

Also, the extra classes (.w-100 and .d-block) are unnecessary and will make it harder for devs using this lib to override the default Bootstrap behaviour if needed. Divs are already block elements and are naturally 100% width and display block.

@dyve
Copy link
Member

dyve commented Oct 19, 2025

Should we revert #767?

@ppfeufer
Copy link

Should we revert #767?

And replace with the proper markup - #767 (comment)

{% if field_errors %}
    <div id="{{ field.auto_id }}_error" class="invalid-feedback">
        {% for text in field_errors %}
            <div>{{ text }}</div>
        {% endfor %}
    </div>
{% endif %}

dyve added a commit that referenced this pull request Oct 19, 2025
dyve added a commit that referenced this pull request Oct 19, 2025
@xi
Copy link
Contributor Author

xi commented Oct 19, 2025

Should we revert #767?

I think I explained the reasons why I prefer this solution over the one pushed by @ppfeufer pretty well in #763. It is up to you to decide which one you think works best.

@dyve dyve mentioned this pull request Oct 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Field errors not displaying correctly because of <div id="id_fieldname_error"> wrapper in new version

4 participants