Code

#19251 closed New feature (wontfix)

Normalize newlines from Textarea widgets

Reported by: claudep Owned by: nobody
Component: Forms Version: master
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 claudep 21 months ago.
Normalize newlines from Textarea

Download all attachments as: .zip

Change History (6)

Changed 21 months ago by claudep

Normalize newlines from Textarea

comment:1 Changed 21 months ago by claudep

  • Easy pickings set
  • Has patch set

comment:2 follow-up: Changed 20 months ago by aaugustin

  • Easy pickings unset
  • Triage Stage changed from Unreviewed to Design 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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 20 months ago by claudep

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.

comment:4 in reply to: ↑ 3 Changed 20 months ago by aaugustin

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 20 months ago by aaugustin (previous) (diff)

comment:5 Changed 16 months ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.