SOLVED
1 ACCEPTED SOLUTION
Accepted Solutions
I've always found it strange that you can decide the field type inside the forms to something other than the real type
If the field you are including is a boolean, you could set the type to multi select... or a date field into a string with no specific format... which makes no sense and probably results in errors
Mmm, not so weird, really. All basic HTML form inputs are in fact strings; there is no other way to pass x-www-form-urlencoded data. All apparent typing of fields is by mutual agreement of the (de)serializers on either side, it's not part of the standard.
Even an input mask or type that appears to coerce a field to, say, a number or date is just a UI artifact, not much different from a CSS style that uppercases a value for display but doesn't change the underlying value. The value is still a string:
Of course you can use a few actual datatypes if you build a completely non-standard form and post JSON, like real booleans and nulls. But that isn't a regular form anymore, and even then you can't pass real dates, only date-like strings.
It's vitally important that the Marketo user be able to choose among different input types. You're right, displaying a boolean as a multi-select is unlikely to end well, but the Forms API allows for all manner of preprocessing, so there are plenty of seeming mismatches that are resolved before posting. Even concepts like a checkbox being passed as "yes" or "no" does not conform to any standard (unchecked checkboxes are not posted at all with regular forms) so there is always some mapping of values.
Anyway...
Perhaps a css rule could hide the mirror fields only and then i shouldn't need to set them as hidden?
Yes, that is the way I would do it.
Since you're already using my tag-wrappers script:
.mktoFormRow[data-wrapper-for="yourMirrorField"] {
display: none;
}
I'm not actually using your wrapper yet. I imagine you would advise to use it instead of a a css rule directly?
Well, you have to run tagWrappers() in order to be able to hide the entire row DIV based on the field(s) inside it.
I see.. so actually everything is a long interpreted string of zeroes and ones, and input types are just an agreed upon standard for information exchanges that it makes more sense to us.
I wasn't trying to be quite that general here! 
Of course everything is ultimately binary, but the point I was making is that HTML <input type=date> and <input type=number> fields are not truly "typed" in the data-storage sense. They may have a display mask/input mask, and (in some browsers) special built-in widgets, like spinners or date pickers. But they're storing the selected value as a String.
That's why the spec says that an unrecognized type= must be treated as <input type=text>, and no data is actually lost, just the appearance. When posted to the server, the value "222" is sent as a 3-byte string, not the 1 byte that the number 222 would take; the value "2018-02-01T00:12:14" is 19 characters, not a 5- or 8-byte datetime.
It's because of inefficiencies like this in plain text that custom formats have been created, like protobuf. When supported by browsers, those formats are awesomely efficient, in part because they use the smallest possible number of bytes to send a piece of data and are type-aware. But the server needs to be type-aware as well. This is very different from a regular form post with text <inputs>, which has a prescribed format that is, on the one hand, wasteful -- but is also understood by every browser and every server for the past ~20 years.
.png)