-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't use html in xAPI language fields #10
Comments
Thanks. HTML is prohibited in all language fields ? What is the standard way of representing newlines ? |
Yes. Strictly speaking it's not probihited but the field is plain text so any html should be assumed to be part of the text, e.g. in an exam question about html: See https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-Data.md#42-language-maps I don't think there's any good way to include new lines in those fields. |
I see, thanks for the clarification. |
You can include html in extensions yes, but if you do that i recommend also including the plain text version in the normal field. Can you give an example of what you mean for the long-fill-in? |
Yes, i see. An example of a long-fill-in would be several sentences that you would want to separate with line-breaks or other styling. A bad example:
You don't want these to appear on the same line in a report. |
Is this for the object.definition.name.en field? I don't have a good solution for including line breaks in that field. Sorry! |
I'm sorry. This is in the object.definition.description.en-US field as well, that was a bad example.I could not find any good examples where html was needed as part of a field other than language field. I suppose that is where it is most needed, at least in our use cases. Do you have any suggestions for how to model an xAPI statement like H5P.DragText that has the 'matching' interaction type in between words. Or a 'long-fill-in' like H5P.Blanks that has multiple 'fill-in' mixed into the sentence. I could not find any examples of this use-case. Does it make sense to have the text with placeholders in object.definition.description and then a separate extension for the formatting ? Or should the object.definition.description be as small as possible, without the actual task text, e.g. just 'drag the words to the correct dropzones' and a separate extension for the actual task with the formatting ? Anyway I suppose any additional (formatted) info needed for generating reports, and for providing metadata should be included as an extension ? |
My assumption is that you are just asking for examples of the description field rather than the complete statement. Is that right? In that case, then i think that the approach H5P currently uses of inserting ______ for blanks makes sense. e.g.
|
Yes, that's exactly what I was looking for. Thanks a lot. |
The description.en-US field concatenates the Task Description and Text Field with a
<br/>
tag to separate them. HTML is not allowed in these fields however and will lead to formatting problems when the data is displayed in reports not specifically designed for H5P. Instead, I recommend separating these fields by a space or possibly even some text e.g.<task description> Text Field: <text field>
The text was updated successfully, but these errors were encountered: