Repeating sections cannot display attributes whose inputs have no type (Character Sheet Development)

Inputs in repeating sections need to be explicitly types as text in order to display information within the repeating section template. If an input is included with no type, it behaves improperly and may not store data. This code will reproduce the issue: < h3 > Skills < /h3 > < fieldset class = "repeating_skills" > < button type = "roll" name = "roll_skill" value = "/em uses @{skillname}, and rolls [[@{dtype}]]" > <span name="attr_skillname"></span> < /button >    < input name = "attr_skillname" value = "" > < select name = "attr_dtype" class = "dtype" > < option value = "d6" > d6 < /option > < option value = "d10" > d10 < /option > < /select > < /fieldset > while this code will work as expected: < fieldset class = "repeating_skills" > < button type = "roll" name = "roll_skill" value = "/em uses @{skillname}, and rolls [[@{dtype}]]" > <span name="attr_skillname"></span> < /button >    < input type="Text"name = "attr_skillname" value = "" > < select name = "attr_dtype" class = "dtype" > < option value = "d6" > d6 < /option > < option value = "d10" > d10 < /option > < /select > < /fieldset > Text is the default type for input so these two code snippets should behave the same way. Description of setup Browser + Version: Firefox 98.0.2 Browser Addons/Extensions: None applicable Operating System: Linux

Yyyyyyyeah, that probably isn't a great idea, even if you're the only one working on the code. Javascript (or jQuery, which Roll20 uses) and CSS are going to be tripped up by that if they try to use the [type=] selector. That's going to ruin some inbuilt functionality (as you've discovered) and also frustrate anyone trying to do CSS on top of your HTML. That's on top of best practices, readable code, yaddah yaddah yaddah... Possibly worth adding to the character sheet development quirks though.

You should always define type for inputs, so not really a bug, roll20 just enforces some HTML best practices.