Table field

In the first implementation of this feature the user data strings saved in the database are only parsed on the client, never on the server. This matches current synchronization functionality where field value data is never modified. The downside for now is that the sync can't reorder the data based on user changes to the columns setup.
It is possible for cells to completely not match the column headers by content or even count. That may not be ideal, but makes for easier version 1 implementation, and even grossly odd differences won't break anything when rendered.
- If there are more header cells than cells per row in existing data, the edit page will provide additional inputs for the new columns.
Synchronization will always make the existing headers match the headers in the template.

There are 3 ways the string can be rendered as a table by the JavaScript:

<span class="tableField" colHeads="First%%Two%%See">A%%B%%C||1%%2%%3</span>

<input type="text" class="tableField" colHeads="First%%Two%%See" value="A%%B%%C||1%%2%%3" />

<td class="g15">A%%B%%C||1%%2%%3</td>

The global settings file contains a max columns limit.

There is no built in row limit

Import and download uses the raw delimited format. The user can use shells to translate the raw data into something more meaningful.

The import doesn't process or validate the data other than removing potentially dangerous input. This means a user could import a hundred cells in a row to a table field setup for 4 columns. It's out of the scope of this version to catch that and it will be trimmed when displayed or edited using the JavaScript render. In other words, the business logic treats table field input as just a string and never parses it into a table.

Misc

By design column headers are kept out of cell data (could've used 3rd level delimiter) so import doesn't have to worry about them and display/download in grid is optional.
Future versions may include custom column data types