My opinion : it's done for JS, not for css.
And if we allow script tag : we can not put it at the needed place by the theme.

PS : for CSS : it's easy to do a addCssToQuestion : https://gitlab.com/SondagesPro/QuestionSettingsType/addScriptToQuestion
BUT : i think it's better to have a Group settings here.

My opinion : it's done for JS, not for css.
And if we allow script tag : we can not put it at the needed place by the theme.

I do not understand how we could place this when it was in the question text tab.

BUT : i think it's better to have a Group settings here.
I do not understand what you mean here.

I do not understand how we could place this when it was in the question text tab.

in header, in footer, ready or just after answers

I do not understand what you mean here.
CSS is not related to question, but to page (~group).

In my opinion : if you add question css : you must add #question{QID} for all css line .

in header, in footer, ready or just after answers

As survey developer, we were never able before to do this. So why this reason?

CSS is not related to question, but to page (~group).

If this is a serious reason, then I would expect also to have a code tab at the group edit screen. Your remark may be true, but does it make a difference in this issue?

About CSS : i say it's easy to create a addCssToQuestion
But still : it's more related to page

As survey developer, we were never able before to do this. So why this reason?
Can be done since years in addScriptToQuestion, i have the utility one time (adding just after answer, but in doc.ready for another question)

If this is a core feature, let it be a good core feature. If the core feature cannot be implemented right, a plugin can come to the rescue, but plugins are for many people much more difficult to install/use.

You seem to say: this feature is crap, so use my plugin? Why not make it a good feature? Or do you propose to delete the feature and just use a plugin? You say it is easy to develop, but why develop a plugin when the feature is already (half) in core?

I seem to see several features that are more or less good, and then a plugin with a better feature set comes up. Even for me, as a user that is quite close to development, this is quite difficult to understand when to use what.

And it is difficult to teach to users.

Current feature is done for JS , not CSS .

My plugin is far more older than the 4.X version … work in 2.6 …
And I propose to add it in LimeSurvey core years ago.

Hi All. Is it ok to classify this as a feature request?

I guess not: this feature was a result of a previous feature request that was (in my opinion) not implemented right.

The feature request is about javascript , neither about CSS style.

Strictly speaking you are right. But when this would have been discussed< i would have added that it would be best if the complete javascript could be added (with <script> tag) and that additional CSS could also be added: both javascript as well as css can be added in the question text, but they confict with the GUI of the editor.

By separating them, you make life easier for users.

By leaving the javascript in tact, you do not frustrate users that read the great solutions by tpartner that now have to be handled differently when you want to use this (badly implemented) feature. Tpartner dows not use it, he might use it when the extra tab can receive the same code as the question text.

when the extra tab can receive the same code as the question text

Then : use question text …

I really don't understand the point here …

For "normal" users, people that are not software developers adding a question with a HTML editor is something completely different from adding code (Javascript or CSS) to a non-HTML editor.

The requested feature hoped to achieve this, but I think I was misunderstood. Of course people are still able to add javascript or css to the question editor, but often this leads to errors due to the HTML editor itself. I want to avoid that and make it easier for non-developers.

I guess we could add some pre and post html before the textarea mimicing the <script> and </script> tags.
That way, people will not be confused about wether those tags should be included or not.

That would already help (for 50%...), because people following tpartner's instructions on the forum and adding to the script tag now get confused.

Still I think it would be better to not "think for the user" and not automatically add the tags, that way css can also be added.

About css : the issue : it's not related to question, clearly not …

A real solution can be

• Adding a CSS box to theme option
• Sanitize this css if you allow XSS user to
• Use class

About CSS: it was clearly related to my feature request: i wanted (but did not ask clearly enough) a tab for additional code.

What was developed was a solution for javascript, but not for CSS. So in my view this was a 50% solution and not a fgood one, since this solution makes people that look in the forum for javascript "tricks" confused:

• when you follow tpartners instructions, you add the complete script to the question text

• when you add the script to a script/code tab, you have to leave away a part, which was never indicated

• often tpatner solution also include css, which was also added to the question text, but now you still have to add it there, because the code tab does not accept it.

• adding it to the theme option was never mentioned, and then it it cut loose from the solution. Several users cannot use the theme options

• use a class: that is what is now added to the question text. Of course I know that I can add it to the custom.css, but for many users this is "scary"

The way we did it (adding extra code to the question text), was clever. I just wanted to make it more clever by having an extra tab, so that there is a clear separation or text and code. But this solution makes it more difficult and less clear for users.

And when I say "users", I mean people that are not developers themselves.

Several users cannot use the theme options

???? Survey creator must have all access to Survey theme option.

And when I say "users", I mean people that are not developers themselves.
I know that … and i think current way is more complex than my plugin …

???? Survey creator must have all access to Survey theme option. >> They do not know how to use.

Plugins are great, but currently too much hidden from novice users.

We are too much doing a yes/no game here and we will not convince each other via this medium.

I think this (as an example for also other feature requests) could benefit from a more brainstorm like meeting online or live.

This would be great to do when we could have a yearly meeting of core users/partners.

They do not know how to use.

They don't know how to use style … you can broke completely a survey with only CSS …

Plugins are great, but currently too much hidden from novice users.

When it's activated it's like any other advanced question settings …

I think this (as an example for also other feature requests) could benefit from a more brainstorm like meeting online or live.

Yes +1

Else :

when you follow tpartners instructions, you add the complete script to the question text

The n adding a "no HTML" helper on all question ? Where user can add anything but without HTML editor ?

Something like

1. Question->text (HTML editor)
2. Question->help (HTML editor)
3. Question->extra : no HTML editor, added after answers (according to Survey-theme)

It's your feature request ?

Something like

Question->text (HTML editor)
Question->help (HTML editor)
Question->extra : no HTML editor, added after answers (according to Survey-theme)

It's your feature request ?

YES, that was my feature request.

In stead of the current javascript tab.

Can this be transferred to "Feature requests"?

Category : workaround ?
;)

Not sure if I understand. I think this can be a feature that helps people a lot. In stead of the current JS-tab, which will not much be used, I guess, when TPartner says he does not use it...

I like the feature. Clearer separation allows possibilities of better handling in the future.
I would implement this at group level as well

TPartner says he does not use it...

Unsure Tony use a lot 5.X

Some of my client are really happy of scriptAttribute : allow to be updated by superadmin and not deleted by other user. More hidden then the current one.

Personally : i don't care : i always use HTML editor as popup … it's the 1st thing i do when i'm connected on a new instance.
I don't see real interest of this feature :)
sorry.

@Denis: that was already clear from your answers... ;-)

;)

I already have a feature request about "set default HTML editor to popup" sowewhere …
Surely a 5 years feature request :p