--
Ticket URL: <https://code.djangoproject.com/ticket/24871>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* Attachment "widgets.patch" added.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
Those characters are to fix #8627. Has the situation with how browsers
handle that situation changed or do we have two different use cases such
that we have to make a decision which one to support?
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:1>
Comment (by timgraham):
The test added in #8627 does fail in Firefox if the proposed patch is
applied.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:2>
* Attachment "textarea1.html" added.
* Attachment "textarea1.xhtml" added.
Comment (by tompecina):
I added two more files, simple test forms. Their contents is practically
identical, except that one is .html and the other .xhtml. Both Chrome and
FF display them differently.
Thus, in my opinion, #8627 did not take into account the differences in
behavior of browsers in XHTML mode, and the original patch should be
reviewed. A clumsy, though practicable, workaround is to add the extra
newline only if the content generated is (plain) HTML.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:3>
Comment (by timgraham):
For what it's worth, Rails also
[https://github.com/rails/rails/blob/390449ab8c55dacc08517bc270c6203bb1f50e02/actionview/lib/action_view/helpers/tag_helper.rb#L25-L27
adds a leading newline] ([https://github.com/rails/rails/issues/393
issue]).
I don't see a good way of making the newline conditional on whether the
widget is being rendered as HTML or XHTML as the widget doesn't have
knowledge of that.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:4>
Comment (by tompecina):
That's right, so the information weather to add a newline would have to be
supplied by the developer somehow, eg, in a settings variable.
To sum it up, standard HTML requires a leading newline as all browsers are
required to ignore it, by the HTML standard. Stripping it would break a
lot of existing code because leading newlines cannot be safely stripped,
as is the case with CMS's, etc.
On the other hand, when Django is outputting XML-serialized code, there is
no way to get rid of the extra newline, except using a custom Textarea
widget.
I see no easy way out, the "lesser evil" appears to be a new settings
variable.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:5>
Comment (by timgraham):
The problem with a setting is that it forces a project to choose XHTML or
HTML (can't use both together). `contrib.admin`, for example, requires
HTML (#23908).
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:6>
Comment (by mjtamlyn):
New settings are definitely not the lesser of the evils!
I'm severely unconvinced we should be careful about support for XHTML5. IE
doesn't support it, and it seems to be a much more non-standard practice
than it was in html4 days. I would suggest maybe a documentation note with
the text area widget, but I'm borderline to just closing this.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:7>
Comment (by tompecina):
If I had a time machine, I could easily find out if the XML-serialized
HTML (aka "XHTML5") has any future. But I don't have one and at the
moment, there are people - including me - using the XHTML format, and
these are made to create custom textarea widgets. The primary problem is
the inconsistent behavior of browsers (due to a failure of HTML/XML
authors to deal with the whitespace trouble more elegantly in the first
place). Therefore, it might be a good idea for Django to address this
issue, by way of a settings variable or a widget parameter (or both).
Well, if XHTML is dead, let's forget about it and close the ticket as
obsolete and antiquated.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:8>
* stage: Unreviewed => Accepted
Comment:
I think a setting to control this is a non-starter, and we can drop it
from consideration. No other aspect of form widget rendering (or really,
form behavior in general) is configured via settings. Not to mention Tim's
objection, which is that a project wide setting fails to account for a
project which may need both behaviors (eg because it is mostly XHTML5 but
uses the admin).
Creating a custom widget subclass is not onerous. I do it all the time,
for all sorts of reasons. My inclination is that that's an adequate
solution for this case.
That said, I wouldn't have any problem with a `prepend_newline` parameter
to `Textarea` which defaults to `True`. The justification for this is not
so much XHTML5 specifically, and more just that the automatic new line
stripping is conceptually odd behavior to begin with, added by browsers to
workaround careless markup, and it seems reasonable to have a way to avoid
that workaround and revert to what would otherwise be the straightforward
intuitive behavior for the `Textarea` widget (that is, leaving the
provided contents alone).
I do think the added new line behavior is something that ought to be
documented regardless. Accepting this ticket on the basis that at least
docs should be added.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:9>
Comment (by tompecina):
The problem is not with having to subclass the widget (I never use non-
custom widgets in my projects anyway) but that there is currently no
elegant way of doing it; as a tentative and provisional fix, I'm
overriding the {{{render}}} function with taking whatever the superclass'
{{{render}}} returns and replacing the newline after the first ">" with an
empty string, like this:
{{{
def render(self, *args, **kwargs):
return mark_safe(super(taw, self).render(*args,
**kwargs).replace('>\r\n', '>', 1))
}}}
Having a widget parameter would definitely be nice.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:10>
Comment (by carljm):
Yes, good point - I can see that in this case there's no elegant way for a
subclass to change this behavior.
A more general solution would be to move the HTML template into a class
attribute that a subclass could override (or one of these days finally fix
#15667).
On further thought, I think I'm more inclined towards the class attribute
than the parameter. The goal is to eventually move towards #15667, and
once we arrive in that world (where all widget markup is overrideable via
the template system) the existence of such a specific parameter for
changing one aspect of rendering a `Textarea` would seem a bit of a wart,
I think. Whereas moving the HTML template of a widget to a class attribute
is consistent with other existing widgets, and offers a flexibility that's
more similar to that of template-based widget rendering.
Is anyone opposed to moving the HTML template for `Textarea` to a class
attribute of the widget?
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:11>
* status: new => closed
* resolution: => wontfix
Comment:
Closing since #15667 is close to merge.
--
Ticket URL: <https://code.djangoproject.com/ticket/24871#comment:12>