Chained attributes are assigned in reverse order

[jazzband]

Chained attributes are assigned in reverse order

[kmike]

Django widgets' 'attrs' argument is a dictionary so the order of atributes should not be relied on. This is how django widgets work so I don't think we should do anything here.

Current django-widget-tweaks tests just check if e.g. name="simple" is in rendered widget and name='complex' is not - this is not totally great but works good enough for tests.

django 1.4 has assertHtmlEqual that can be backported to django-widget-tweaks and used for such tests. I don't have strong opinion here but think that this may be too much.

[kmike]

Sorry, I misread the original report. This is indeed counter-intuitive.

[kmike]

Extra example to consider:

{# inc/field.html #}
{% load widget_tweaks %}
<div>{{ field|attr:"foo:default_foo" }}</div>

{# my_template.html #}
{% load widget_tweaks %}
<form method='POST' action=''> {% csrf_token %}
    {% include "inc/field.html" with field=form.title %}
    {% include "inc/field.html" with field=form.description|attr:"foo:non_default_foo" %}
</form>

this should work with current implementation but will not be possible if we change the direction filters are applied.

I agree that the current behavior is counter-intuitive but it seems to have its advantages. Are there use cases for the changed filter direction?

[treyhunner]

I noticed this because render_field relies on set_attr and append_attr so assigning an attribute twice results in the first assignment taking precedence:

{% render_field form.simple foo="bar" foo="baz" %}

Renders

<input foo="bar" type="text" name="simple" id="id_simple" />

For render_field I don't think this is really an issue because there is no use for multiple attribute assignment.

I have not thought of any good use for attr chaining either.

[kmike]

I take a step further and document the current filter application order. Thanks for raising this issue!