Changed "Enter Value" to "Add Remarks"

[KeeyanGhoreshi]

trafficstars

Fixes #219 with a CSS change, making the content when the text area is empty "Add Remarks" instead of "Enter Value", and restricting the behavior to the first child of the parent span so that empty lines don't have "Add Remarks" on them.

Previously empty newlines would be considered as an empty span and have their content set to "Enter Value". The new class allows for empty lines, but still will put a stray "Add Remarks" if the first line if it is left empty.

[KeeyanGhoreshi]

The most recent changes address #68. Instead of a CSS change I edited the behavior of the text area to only allow non-empty spans, since white space gets represented as a <br /> anyway. If there are no spans in the remarks section, an empty one is added to ensure that the "Add Remarks" text shows up. This is because if you add a couple of empty new lines, you'll get a bunch of breaks but no span, and the CSS won't have an empty span to put the "Add Remarks" text in.

These changes allow for free use of white space. There is a very small issue, though, in that the padding changes in the style only affects the first line.

edit: The small padding issue was easier to fix than I thought so everything should be good now.

[arscan]

I'm not sure if this fixes #68 (and my suggestion wouldn't either). I think the intent of that issue is to make it so that remarks that were entered in json, formatted into arrays so that it reads nicely, don't get breaks added when viewing it in the module builder because it causes strange line wrap behavior. It is actually a nontrivial problem to solve, because there are times when we would want to preserve the line breaks... like when somebody puts in a line of ------------------, or maybe if somebody puts in multiple breaks.

[arscan]

Spoke with @KeeyanGhoreshi . He's fixing some of the style suggestions I made, and we'll merge this in after. This isn't attempting to fix #68 after all, we'll tackle that at some point in the future.

[KeeyanGhoreshi]

Speaking of #68, the way remarks are put into the JSON is a bit bizarre. There's no difference between a new line for styling purposes and a new line that's actually desired or useful. New line here means another entry in the array. For a continuous paragraph, its separated out in the JSON and that gets represented in the module builder. Is there a reason to separate it into the array? Shouldn't paragraphs be one entry in the array, instead of multiple?

If you type into the remarks editor, you get one long entry into the array that wraps nicely and doesn't have any issues. For example, modules that were made entirely in the module builder (like my cystic fibrosis module) don't have this issue, paragraphs are one entry in the array.

I don't think this issue really has a "fix", there's no way to concatenate the array into paragraphs because you don't know the intent of the writer. The problem is the styling of the JSON remarks, in that they're hand-wrapped by making multiple entries into the array. But since the remarks editor can be resized, that's going to cause wrapping issues.

[arscan]

Modules used to be be exclusively edited by hand, so the format is optimized for text-editors. You can't represent line breaks in json like this:

   {
      remarks: 'You aren't allowed to do something like this in json
                where multiple lines are put into one single string
                which is why each line is an entry in an array'
   }

instead it would be a long line, which isn't readable at all in traditional editors. It is like having a single line of code be extremely long... sure, it works, but it isn't very readable. So the only real option is to use array elements to represent each line.

I think it is a good practice to have these modules be optimized for human-readability without the requirement to edit them through a tool (e.g. the module builder), as we are using git to review diffs / changes. Anyone that has tried to use git with files that are nominally human readable but really intended to be edited with tool support knows how painful that can get.

Yeah, it isn't easy. I was envisioning putting a few simple rules that give hints for how they should be rendered. Namely, I was thinking that we could do something like wrap single line breaks, but if the 'author' wants to start a new paragraph, or force a new line start, then they have to enter in a blank "". Then we use some kind of line-wrap algorithm on save so that the JSON that gets saved has short lines.

Happy to discuss further if you strongly disagree though.

[arscan]

To be clear though, let's keep those issues separate. If you are interested and available you are free to tackle that issue separately. (I'll reference these comments in that issue, we should really be having this conversation over in #68)