Re: Changing widget rendering templates

[Carlton Gibson]

Hi David. 

Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)

I'd say option 1: It's an accessibility change and we should just opt 
people into that. IIRC there are some small improvements to the current 
HTML (aria roles and such) that would improve accessibility even if not 
perfectly. We should add those. (Folks can revert to the old templates if 
they must, assuming we note the changes.)

With the template based rendering in place, I'd think (though) we could 
eventually move away from `as_p` &co. 
Rather you'd set the (base) `template_name` for the form, or override 
`django/forms/default.html`, which in the PR proxies to `table.html` to 
maintain the current behaviour, and then rely on `__str__()`, i.e. you'd do 
`{{ form }}`. 

If we keep `table.html`, `ul.html` and `p.html`, folks who are using `{{ 
form }}` now can add the `as_*` as needed to keep the current output 
(modulo the aria type changes). 

We should then be free to introduce a better `default.html` that addresses 
the accessibility issues more comprehensively. I think there's no problem 
heading towards this. 

I think we do have to leave that fallback though: I'd guess the number of 
projects using `as_p` &co somewhere is legion; just changing the HTML would 
be a pretty big break without a fallback... 🤔 Whether it's worth the 
disruption to formally deprecate and remove these methods I don't know... 
We could add a warning to as_p &co to say "This method 
has accessibility issues" if we wanted to steer people away — There's 
probably value if having two or three different examples of how you could 
render a form, especially if we can solve the worst of the accessibility 
concerns.

Kind Regards,

Carlton


On Friday, 4 June 2021 at 08:56:12 UTC+2 smi...@gmail.com wrote:

> Hey all,
>
> I've been looking at the couple of tickets open to improve accessibility 
> of the forms and checkbox/radio widgets. [1][2]
>
> While changing the layout is _fairly_ straight forward I'm unsure how to 
> transition to the new way. I'm focusing this change in changing the widget 
> templates until the patch for template based rendering of forms is merged.
>
> I think the options are:
>
> 1) Just make the change and have a breaking change. 😬
>
> 2) Introduce the new template and deprecate use of the old template. This 
> is really horrid as _everyone_ will have to add boiler plate template over 
> rides to point at the new template. We'd then probably want to change the 
> name again at the end of the depreciation period. 
>
> 3) Change the default template and package the old template, folk can then 
> over ride their template if they still want the old behaviour. We can then 
> deprecate the old template, and folk can include it their selves if they 
> want it longer term. While a breaking change there would be a _simple_ 
> solution.
>
> I hope this is enough to get your creative juices going! I'm hoping there 
> is a better way than what I can think of.
>
> My gut reaction would be to go for option 3.  We don't have any data on 
> how well used the default templates are used, I'm guessing it's not used 
> that much...
>
> Appreciate your thoughts. 
>
> Kind Regards
>
> David
>
>
> [1]https://code.djangoproject.com/ticket/32338
> [2]https://code.djangoproject.com/ticket/32339
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/65637a91-d3b9-4031-aa3c-b737017fdd70n%40googlegroups.com.

Re: Changing widget rendering templates

['Adam Johnson' via Django developers (Contributions to Django itself)]

I think a breaking change for the widget HTML is fine too, if it improves
everyone’s apps. Perhaps documenting in the release notes how to undo it
(eg copy this template file into your project, reconfigure the widget to
use the template like so) will make it easier for folks with incompatible
CSS to upgrade.

On Sat, 5 Jun 2021 at 08:45, Carlton Gibson 
wrote:

> Hi David.
>
> Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)
>
> I'd say option 1: It's an accessibility change and we should just opt
> people into that. IIRC there are some small improvements to the current
> HTML (aria roles and such) that would improve accessibility even if not
> perfectly. We should add those. (Folks can revert to the old templates if
> they must, assuming we note the changes.)
>
> With the template based rendering in place, I'd think (though) we could
> eventually move away from `as_p` &co.
> Rather you'd set the (base) `template_name` for the form, or override
> `django/forms/default.html`, which in the PR proxies to `table.html` to
> maintain the current behaviour, and then rely on `__str__()`, i.e. you'd do
> `{{ form }}`.
>
> If we keep `table.html`, `ul.html` and `p.html`, folks who are using `{{
> form }}` now can add the `as_*` as needed to keep the current output
> (modulo the aria type changes).
>
> We should then be free to introduce a better `default.html` that addresses
> the accessibility issues more comprehensively. I think there's no problem
> heading towards this.
>
> I think we do have to leave that fallback though: I'd guess the number of
> projects using `as_p` &co somewhere is legion; just changing the HTML would
> be a pretty big break without a fallback... 🤔 Whether it's worth the
> disruption to formally deprecate and remove these methods I don't know...
> We could add a warning to as_p &co to say "This method
> has accessibility issues" if we wanted to steer people away — There's
> probably value if having two or three different examples of how you could
> render a form, especially if we can solve the worst of the accessibility
> concerns.
>
> Kind Regards,
>
> Carlton
>
>
> On Friday, 4 June 2021 at 08:56:12 UTC+2 smi...@gmail.com wrote:
>
>> Hey all,
>>
>> I've been looking at the couple of tickets open to improve accessibility
>> of the forms and checkbox/radio widgets. [1][2]
>>
>> While changing the layout is _fairly_ straight forward I'm unsure how to
>> transition to the new way. I'm focusing this change in changing the widget
>> templates until the patch for template based rendering of forms is merged.
>>
>> I think the options are:
>>
>> 1) Just make the change and have a breaking change. 😬
>>
>> 2) Introduce the new template and deprecate use of the old template. This
>> is really horrid as _everyone_ will have to add boiler plate template over
>> rides to point at the new template. We'd then probably want to change the
>> name again at the end of the depreciation period.
>>
>> 3) Change the default template and package the old template, folk can
>> then over ride their template if they still want the old behaviour. We can
>> then deprecate the old template, and folk can include it their selves if
>> they want it longer term. While a breaking change there would be a _simple_
>> solution.
>>
>> I hope this is enough to get your creative juices going! I'm hoping there
>> is a better way than what I can think of.
>>
>> My gut reaction would be to go for option 3.  We don't have any data on
>> how well used the default templates are used, I'm guessing it's not used
>> that much...
>>
>> Appreciate your thoughts.
>>
>> Kind Regards
>>
>> David
>>
>>
>> [1]https://code.djangoproject.com/ticket/32338
>> [2]https://code.djangoproject.com/ticket/32339
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/65637a91-d3b9-4031-aa3c-b737017fdd70n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2vD%3Dhy-gHQ%2BaCRS7s9bR8MEXWqcSEauGtkBBpN38m-PQ%40mail.gmail.com.

Re: What to do about formfield_callback?

[James Bennett]

On Fri, Jun 4, 2021 at 11:54 PM Carlton Gibson  wrote:
> I'm sympathetic to the suggestion here, but wary of expanding the Forms API, 
> which already has a number of different ways of holding it.
>
> > ...to impose uniform custom widget attributes and error messages across a 
> > bunch of ModelForms...
>
> My initial query is, would not defining `field_classes`[1] on, say, a base 
> form class for your project be a/the way to go here?

Without getting too far off into details, the basic issue is I have an
app where there are a lot of ModelForms, and for certain model field
types we want the form field to always get set up in a way that
differs from Django's defaults (think of, say, always wanting a
particular custom widget setup, or custom error messages, for a
particular model field type).

It's a thing that you *can* do by writing out overrides or
re-declarations of the relevant fields on each form. But when you have
dozens of forms and there's no consistent pattern to the naming of the
fields you want to override, it gets really tedious to write out and
maintain all those overrides.

Which is why the code uses formfield_callback -- that is Django's
customization hook for this type of "every instance of model field of
this type, output a form field of this type" stuff. And it's already
crept into documented API, to some extent, because the model
form/formset factories document it as a parameter.

So I'd just like for it to become proper fully-documented API with
consistent behavior (since right now its behavior and effect varies
according to how you specify it and how you construct your forms).

(the only other real alternative right now is to go write a custom
model field subclass and implement formfield() on it, then go migrate
a bunch of models to use the new custom field instead of the default
Django one. But it feels odd and wrong to me that form-only behavior
would need to be overridden in the model rather than in the form)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8thHw7Sj-8KoAzU4J0QgWo9EXMNXDw1jkt2QtZBvDf5g%40mail.gmail.com.

Re: Changing widget rendering templates

[Thibaud Colas]

Hi all,

I wanted to mention a couple more things that might help in the decision:


   - There is no direct accessibility issue *for end users* from `as_p` 
   that I know of. The only issue is its propensity to making people create 
   forms with invalid HTML (see #31189 
   ), which is problematic 
   when running HTML validation, and is a failure of WCAG 2.1 level A SC 
   4.1.1 Parsing  
(this 
   standard being the most likely target for Django, although there is no 
   official target as of now).
   - I’ve just opened two tickets that, if confirmed, would require 
   additional changes to the widgets’ rendering to fix: #32819 
   , #32820 
   .

I imagine we want to release changes to forms’ rendering as infrequently as 
possible. If we considered grouping those changes all in the same release, 
it could be worthwhile for me to further review forms and fields for any 
further issues there might be, so they can be fixed at the same time. One 
problem I’m facing with this and similar audits is that I almost never use 
Django’s default markup myself, so it would be nice for others to look at 
the form I’m using for testing (code 

, rendering ) 
and confirm it’s suitable. Or provide alternative forms you might already 
be aware of, set up differently or showcasing more advanced widget 
configurations.

Those additional tickets reflect the extent of my audit progress to date. 
One thing I’m considering but am uncertain of is whether non-field errors 
would also need ARIA markup, to be more identifiable as errors, and-or 
programmatically associated with the form. I still need to research this, 
both according to specs, and with actual support from screen readers.

Kind regards,

Thibaud

On Saturday, 5 June 2021 at 09:31:54 UTC+1 Adam Johnson wrote:

> I think a breaking change for the widget HTML is fine too, if it improves 
> everyone’s apps. Perhaps documenting in the release notes how to undo it 
> (eg copy this template file into your project, reconfigure the widget to 
> use the template like so) will make it easier for folks with incompatible 
> CSS to upgrade.
>
> On Sat, 5 Jun 2021 at 08:45, Carlton Gibson  wrote:
>
>> Hi David. 
>>
>> Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)
>>
>> I'd say option 1: It's an accessibility change and we should just opt 
>> people into that. IIRC there are some small improvements to the current 
>> HTML (aria roles and such) that would improve accessibility even if not 
>> perfectly. We should add those. (Folks can revert to the old templates if 
>> they must, assuming we note the changes.)
>>
>> With the template based rendering in place, I'd think (though) we could 
>> eventually move away from `as_p` &co. 
>> Rather you'd set the (base) `template_name` for the form, or override 
>> `django/forms/default.html`, which in the PR proxies to `table.html` to 
>> maintain the current behaviour, and then rely on `__str__()`, i.e. you'd do 
>> `{{ form }}`. 
>>
>> If we keep `table.html`, `ul.html` and `p.html`, folks who are using `{{ 
>> form }}` now can add the `as_*` as needed to keep the current output 
>> (modulo the aria type changes). 
>>
>> We should then be free to introduce a better `default.html` that 
>> addresses the accessibility issues more comprehensively. I think there's no 
>> problem heading towards this. 
>>
>> I think we do have to leave that fallback though: I'd guess the number 
>> of projects using `as_p` &co somewhere is legion; just changing the HTML 
>> would be a pretty big break without a fallback... 🤔 Whether it's worth the 
>> disruption to formally deprecate and remove these methods I don't know... 
>> We could add a warning to as_p &co to say "This method 
>> has accessibility issues" if we wanted to steer people away — There's 
>> probably value if having two or three different examples of how you could 
>> render a form, especially if we can solve the worst of the accessibility 
>> concerns.
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Friday, 4 June 2021 at 08:56:12 UTC+2 smi...@gmail.com wrote:
>>
>>> Hey all,
>>>
>>> I've been looking at the couple of tickets open to improve accessibility 
>>> of the forms and checkbox/radio widgets. [1][2]
>>>
>>> While changing the layout is _fairly_ straight forward I'm unsure how to 
>>> transition to the new way. I'm focusing this change in changing the widget 
>>> templates until the patch for template based rendering of forms is merged.
>>>
>>> I think the options are:
>>>
>>> 1) Just make the change and have a breaking change. 😬
>>>
>>> 2) Introduce the new template and deprecate use o