Opened 11 years ago

Closed 11 years ago

#19251 closed New feature (wontfix)

Normalize newlines from Textarea widgets

Reported by: Claude Paroz Owned by: nobody
Component: Forms Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently, newlines from Textarea may come in at least two different formats. Most browsers send them as CRLF. But when sent from JS (AJAX), it depends on the browser (Firefox and WebKit seem to send LF-only).

I would suggest to normalize them to LF in all cases. This may also solve the issue about different char counting between client-side and server-side (http://groups.google.com/group/django-users/browse_thread/thread/3161244a2f119444/5fad134a89039d7b?lnk=gst&q=textarea%2C+max_length#5fad134a89039d7b).

Attachments (1)

19251-1.diff (2.3 KB ) - added by Claude Paroz 11 years ago.
Normalize newlines from Textarea

Download all attachments as: .zip

Change History (6)

by Claude Paroz, 11 years ago

Attachment: 19251-1.diff added

Normalize newlines from Textarea

comment:1 by Claude Paroz, 11 years ago

Easy pickings: set
Has patch: set

comment:2 by Aymeric Augustin, 11 years ago

Easy pickings: unset
Triage Stage: UnreviewedDesign decision needed

If browsers generally send CRLF and we want to normalize, shouldn't we normalize to CRLF — even if our personal tastes are different — to avoid creating regressions for Windows users? For instance if they're building text files from user input, suddenly their files may not display correctly any longer.

Generally speaking, Django is very careful about not altering data sent by the browsers. For instance it doesn't strip whitespace, even though it's a very common request, and it's the right thing to do 99% of the time.

in reply to:  2 ; comment:3 by Claude Paroz, 11 years ago

Replying to aaugustin:

If browsers generally send CRLF and we want to normalize, shouldn't we normalize to CRLF — even if our personal tastes are different — to avoid creating regressions for Windows users? For instance if they're building text files from user input, suddenly their files may not display correctly any longer.

If browsers would systematically return CRLF, you would be right. But this isn't always true, so the situation is already inconsistent and somewhat broken.

Generally speaking, Django is very careful about not altering data sent by the browsers. For instance it doesn't strip whitespace, even though it's a very common request, and it's the right thing to do 99% of the time.

Stripping whitespace is semantically altering content, as leading/trailing space may be wanted and significant (albeit seldom). Changing new line format does not change the content (still semantically speaking), this is only a technical artefact.

in reply to:  3 comment:4 by Aymeric Augustin, 11 years ago

Replying to claudep:

If browsers would systematically return CRLF, you would be right. But this isn't always true, so the situation is already inconsistent and somewhat broken.


I didn't explain it well, but my reasoning was:

  • regular requests always use CRLF: if we normalize to CRLF; we're backwards compatible, if we normalize to LF, we aren't.
  • AJAX requests are browser dependent: no matter which way we normalize, it will have side effects for some people.

Although LF is the preferred line ending on Linux and Unix, it isn't "better" or "more correct". For instance HTTP and SMTP use CRLF everywhere.

In my opinion this is a basic browser interoperability issue that is better left to browser developers / W3C / etc.; but if you're keen on fixing it in Django that's just fine.

Last edited 11 years ago by Aymeric Augustin (previous) (diff)

comment:5 by Aymeric Augustin, 11 years ago

Resolution: wontfix
Status: newclosed

What really happens here is that JS code gets the raw content of a textarea, while Django usually gets the content encoded on submit.

In IE, the raw content has newlines represented by CRLF; in other browsers, it has LF.

I still believe the correct solution is to handle this in JavaScript, for example: http://blog.sarathonline.com/2009/09/javascript-maxlength-for-textarea-with.html

Note: See TracTickets for help on using tickets.
Back to Top