-
Type:
Feature
-
Resolution: Cannot Reproduce
-
Priority:
Critical
-
Affects Version/s: None
-
Component/s: User Interface
-
None
We will need to decide how we are going to handle User/External System (Publishing) text input for things like Descriptions and Comments/Annotations.
If we decide to only allow plain text we will still have to handle carriage returns.
Example:
1.) Blah Blah Blah 2.) More Blah 3.) blah blah x3
is different then:
1.) Blah Blah Blah
2.) More Blah
3.) blah blah x3
Also when dealing with carriage returns we will have to deal with the three different types of carriage returns: /n/r, /n, /r
(Each operating system has their own style)
We might also be required to handle url's inside of descriptions, comments, or licensing textareas.
Which means we might need to also handle html. Which if we allow html we will need to be weary of injected malicious javascript.
Finally if we allow html to be inputted how will we stop someone from changing the format of our page, maliciously or accidentally? How will we keep consistency with href link on if that link opens in a new page or on the same page?
If we decide to only allow plain text we will still have to handle carriage returns.
Example:
1.) Blah Blah Blah 2.) More Blah 3.) blah blah x3
is different then:
1.) Blah Blah Blah
2.) More Blah
3.) blah blah x3
Also when dealing with carriage returns we will have to deal with the three different types of carriage returns: /n/r, /n, /r
(Each operating system has their own style)
We might also be required to handle url's inside of descriptions, comments, or licensing textareas.
Which means we might need to also handle html. Which if we allow html we will need to be weary of injected malicious javascript.
Finally if we allow html to be inputted how will we stop someone from changing the format of our page, maliciously or accidentally? How will we keep consistency with href link on if that link opens in a new page or on the same page?