FormulasQuestion
Add option to set size of input fields
Description of proposed feature
Input fields currently have a fixed size according to the answer type. The size can be tweaked using custom CSS in the question, but this is a bit cumbersome.
It might be nice to have an option to specify the size of the input field, e.g. for each part.
Suggested by @AviNat in #7
Related to this feature request, or perhaps instead of, wouldn't it be more widely useful to make it so that input fields are not a fixed size? I note from a Moodle Forum discussion that Martinez wrote a Javascript code to make it so that input fields re-sized while you typed. This is hugely valuable code but cumbersome to incorporate into every question. We wouldn't need to tweak the size of an input field if it auto-sized based on the input. Is it possible to make that the default behaviour?
You could still have a default starting size for each answer type (number, numerical, etc.), but they all resize as you type.
I think I have found a good solution to offer a setting for every individual input field without adding more clutter to the form. In the near future, I will expand the syntax of input fields to support a width parameter like this: {_0|50px} to have a width of 50 pixels (who might have guessed that) or {_0|10} for a width of 10 chars.
This syntax is fully backwards compatible, because for now, the | is not supported in the definition of an input box.
(Note that I am currently working on that part of the code, so it will probably have to wait until that is done.)
This syntax is fully backwards compatible, because for now, the | is not supported in the definition of an input box.
I don't know if the symbol '|' is necessary or not, but the question already uses the symbol ':' to indicate that the answer is in the form of a multiple-choice question, with radio buttons or with a dropdown menu. For example:
{_0:list} for a list of choices using radio buttons
{_0:list:MCE} for a list of choices using a dropdown menu
If possible, the symbol ':' would be preferable to '|' because it's already in use (and easier to find on the keyboard).
Having the colon for multiple choice settings is exactly the reason why I suggest using another symbol. As soon as the parser sees that other symbol in the placeholder, it knows that we are now parsing the display options. Using the colon makes stuff complicated. Imagine you have a variable called center and have the placeholder {_0:center}. Should that be rendered as radio buttons with data from the variable center or as a centered text field? This is impossible to decide. (And telling the users how they may name their variables is not an option IMHO.)
But I can imagine using the comma instead, e.g. {_0,50px} or {_1,50px:center}.
You are right!
I'm not sure about the comma because it could "eventually" conflict with the decimal comma. I would rather stick to the "|".
No worries, that will not be a problem, because the placeholder is completely independent of the number syntax.
What about if the user sets {_0,50,5px} because he wants to have a 50,5px (i.e. 50.5px) wide answer box.
I'm not trying in any way to push this issue onto your agenda. We can resume the conversation when you work on it.
So as not to forget until then, here are a few options that would be useful in different situations and should also be included:
- width
- auto width
- height
- vertical position (from default position)
- horizontal position (from default position)
- inline-block
- font size
- font type
- text alignment
- colored box
In relation to multiple choice:
- shuffling the options
- more than one choice for radio buttons
- horizontal display of radio buttons
Also, the left padding of the radio button choices should be slightly adjusted.
What about if the user sets {_0,50,5px} because he wants to have a 50,5px (i.e. 50.5px) wide answer box.
That seems extremely unlikely for three reasons:
- Although CSS actually supports "fractional" pixels, it is absolutely uncommon to do that, because browsers use different rules for rounding. (And rounding is necessary, because screens can only show entire pixels.)
- As with all numbers in the context of HTML, CSS or Javascript, such a number would have to be specified with a decimal point. Also, this definition is on the teacher side and the usage of a decimal comma (if it is every implemented) will only be a convenience function for students, but not for the question definition or model answers.
- It is very very hard to imagine a situation where one would feel the need to control the size of an answer box to that degree of precision. Even more so, because -- as mentioned above -- they could not be sure whether the student's browser would render that box with 50 or 51 pixels wide.
The documentation of the feature would simply state that the user can specify a width with an integer possibly followed by the suffix px.
So as not to forget until then, here are a few options that would be useful in different situations and should also be included: […]
I'm all in for giving options to the user. But I think it is a bit too much if we try to implement a full-fledged CSS parser where the user can change almost every single setting. We should limit that to the most important things like width, font-size (which automatically sets the height to a reasonable value; it would seem ridiculous to have a 50px box with a 5px font, for example), alignment and background color.
It is always possible to add more features later if there is a real need for them. By real need I mean that we can simply not fulfil every single feature request. We have to focus on things that lead to improvements for many people and many cases in regular usage. Using a product developed by someone else always means that one must accept some compromises and limitations. For very specific individual cases, it is always possible to do a workaround and you are very good at helping people to find those…
Auto-resizing the input field is a separate topic, because that's not a CSS option, but rather a Javascript driven feature. That can be implemented, of course, but as a next step.
Please note that "inline-block" is not a thing for the fields as they are already rendered inline. That point is taken (see #7) for parts. I will change those in order to let the user choose whether they should be block or inline-block.
In relation to multiple choice: […]
Same: I would set the priority for shuffling the options, because that is currently very cumbersome to do. Having the options displayed horizontally is not a big deal either. (It is however dependent on the width of the screen, so people can not reliably produce a certain layout.)
Having more than one choice is completely different, because it means using the "checkbox" element instead of the "radio" button. That can be added, but it's not a quick win; there will be many implementation details to think about.
Also, the left padding of the radio button choices should be slightly adjusted.
Yes, I noticed that as well. It's an ugly layout at the moment. But that's a general thing. IMHO it would be absolute overkill to let the user control that on a per-field basis. Realistically, there is just no need to be able to have, say, 5px padding for question A and 7px padding for question B.
I agree that providing all CSS options will complicate the UI. Setting the field width is a rather common need and hence deserves focused solution. If there's another common need it can be evaluated as well. In the system I'm developing, hiding a field is commonly used when the field value is set from an interactive graph, but in that case there's special code to interact with the input field. I didn't have any other need that would justify a change in the plug in.
For all other special needs, it is possible to get access to the HTML element and have full control over the element's attributes.
