display:block in.que.formulas .formulation .formulaspart

[leac]

Hi

We noticed that in the latest version, the display value of .que.formulas .formulation .formulaspart was changed from inline-block to block. However, in our courses this change breaks the way the parts are displayed:

For example, if the student has to to answer whether x is larger or smaller than a certain value, we want the 3 components of the answer to display side by side, like this: but withdisplay:block, the components are displayed one under the other, like this:

Would you mind explaining the change, and what's more important - how we should handle a case like the above example?

[AviNat]

worth mentioning, if there's a need to break the line it's easy to do. however undoing the change is hard thanks, Avi

[PhilippImhof]

Sorry for the long delay on this. AFAICS parts should be displayed in blocks, because they are like "paragraphs". Do you disagree? Are you still looking for a solution to this?

[PhilippImhof]

I am closing this as unclear. Please feel free to open it again and provide further clarification.

[dbauer-ets]

Hello Philip,

I reopened this topic because I think it needs to be looked into. Indeed, the input boxes are not always easy to place where you want. It could be easier.

Using display:block or display:inline-block makes a difference on the layout of the elements. We should investigate why the change was made in 2018 and see if we can improve the positioning of input boxes.

[PhilippImhof]

I have had a closer look at it now. W3schools says the following about inline-block:

Compared to display: inline, the major difference is that display: inline-block allows to set a width and height on the element. Also, with display: inline-block, the top and bottom margins/paddings are respected, but with display: inline they are not. Compared to display: block, the major difference is that display: inline-block does not add a line-break after the element, so the element can sit next to other elements.

So if we use inline-block instead of block we only lose the automatic line break which users can add without any problems. On the contrary, if we stick with block, users cannot undo that line break, at least not easily.

I also traced back the modification history. As I understand it, it used to be block. Then, in April 2018 (084f04756d5b0a70764ebcacad51d79e42f3cfc8), it was changed to inline-block and the renderer was modified in order to use span instead of div. This would allow inline parts. Approximately one month later (dd4082560966c03661bfb1e3c92f4132e2214bd8), the change was reverted. I can imagine there might have been negative feedback, because it changed the layout of existing questions. Maybe @jmvedrine can say something about that?

I am inclined to use div with inline-block as a compromise. However, as this has the potential to break the layout of MANY existing questions out there, this is not a minor change. We would have to make that very, very clear in the release notes.

[PhilippImhof]

Just thinking: we could introduce an option (checkbox) where users can select for every part if it is to be shown inline or as a block. All old questions are automatically assumed to have their parts displayed inline. That's full backwards compatibility with full freedom for the future.

[jmvedrine]

Yes I was forced to revert that change because some schools said that it has broken a lot of their questions. My +1 to introduce a new setting and make the default so that existing questions are left unchanged.

[PhilippImhof]

There might also be another option: parts that are inserted via a placeholder could be rendered inline, as they are most certainly placed exactly according to the user's need. And parts that are appended automatically at the end of the question (those without a placeholder) would be rendered in block mode.

[dbauer-ets]

Hello Philipp and Jean-Michel,

We must move forward without rushing people too much, but we must not get stuck because of backward compatibility. If we listened to the latecomers, we would still be on hand-cranked telephones.

I propose the solution adopted, if I have understood it correctly, by certain companies. When there is a major change, the new version is offered, while saying that users can still use the old version but for a certain time only, whether it is said explicitly or not.

Here is what I would do in our case:

• Make the necessary changes so that the input boxes are easier to place, for example with a display:inline-block. This method becomes the default.

• Add a checkbox so users can use the old format, along with a note saying that the old format will no longer be available say at the end of 2023.

• At the end of 2023, no longer offer the old format.

We should refuse to be blocked because some schools don't want to make changes.

[AviNat]

Hello everyone

I would like to relate to the need for backward compatibility We are using Moodle to digital learning at the Ministry of Education is Israel for 7th through 9th grades. We have 4 packaged courses that teachers can use as is with no further effort. the courses include THOUSANDS questions so applying a fix to all of them is a major effort.

if using the new functionality requires flipping a check box in questions we will develop in the future, that seems more reasonable.

developing a Formulas questions requires considerable work. Adding one more checkbox wouldn’t make much a difference

Thank you Avi

[PhilippImhof]

• Make the necessary changes so that the input boxes are easier to place, for example with a display:inline-block. This method becomes the default.

Very good. I will go that path; I am currently refactoring the creation/edit form anyway.

If we go for the checkbox solution, we add a column to the qtype_formulas_answers table, e.g. inline. During the update process, this column will be added to existing databases and the value will be set to 0 to maintain compatibility. For new questions, the checkbox will be enabled by default and set that value to 1, unless the user wants the old style.

• Add a checkbox so users can use the old format, along with a note saying that the old format will no longer be available say at the end of 2023.
• At the end of 2023, no longer offer the old format.

Once the changed is rolled out, the necessary field is in the database, as explained above. It does not make sense to remove it after a while, that would just mean more work for us. (Remove the existing code, write code to remove the information from the database again, testing.)

I refuse to be blocked because some schools don't want to make changes.

I partially agree. There are situations when backwards compatibility must be broken in order to move forward. However, in this case, there is no need to. We can introduce that new feature and offer more flexibility without breaking old questions' layout.

I am with you @AviNat, some teachers have invested a fair amount of time in developing questions using our plugins. And they trust us that we will do our best to keep their questions working.

[AviNat]

Hi Thank you!

While you’re on it, would you consider another improvement: Add an option to specify the size of the input field

Similar to the feature in STACK questions. I have a workaround but would be great to have a built-in solution

Thanks, Avi

[dbauer-ets]

Hello Philipp,

In fact, I didn't think you would attack this issue so soon.

The situation is not critical since we can do pretty much what we want with the existing layout values.

I think we should prepare examples (answer boxes inside text, inside equations, in tables, over images, on separate lines, etc.) to see how we can do different layouts with the existing values, with different tags and properties, with or without placeholders, etc., and if these ways are in fact satisfactory or can be improved.

These examples if placed in the documentation would also be useful to users.

Unless you have already done this exercise, I will prepare these examples for discussion and, in my opinion, before making any changes to the code, i.e. the examples should validate or invalidate the need for making changes, and clearly identify the required changes if any. So please hold on a moment.

[dbauer-ets]

Hello Philipp,

Avi's suggestion of "Add an option to specify the size of the input field", I presume the answer boxes, is something that should be done. There are a few points related to this issue that I would like to discuss with you, a bit later.

[PhilippImhof]

Hello Dominique

No worries at all, I haven't startet this project yet; I am still working on the edit form refactoring. I look forward to seeing a collection of examples. And I think that if we manage to include the two things (selection of block vs. inline display and setting the width of the answer field), that would be a very good improvement for the users of this plugin.

Also, this could probably be done more easily once the rendering of the Formulas Question has been refactored to use mustache templates rather than directly generating HTML output in the PHP script.

[PhilippImhof]

Similar to what I wrote in #45, I will change the syntax in order to allow placing parts with inline-block by using {#1|inline} via their placeholders. That means absolutely no changes to existing questions or the database and more flexibility for question authors without adding clutter to the form.