@Alice.moutinho what are your thoughts on this?

Hi @Arian_Bozorg & @Lucas_Werkmeister_WMDE, i think it is a good improvement!

AFAICT a Codex TextArea with :autosize="true" and :rows="1" gets us most of the way there (in particular, Codex does the autosizing for us, yay), but:

• It still shows up with a height of more than one row even when empty; we might have to update Codex to permit text areas that really look like text inputs until their value exceeds one line.
• We’ll need to prevent line breaks in the input.

@Alice.moutinho could you create some designs for the desired behaviour?

Would we need to update codex to make this work for us, or is there a component that would work?

Hello @Arian_Bozorg & @Lucas_Werkmeister_WMDE ,

i found a case where this problem is always sure to happen - first line / last line of poems - and tried it out on our current UI and it is very frustrating to not be able to see the complete text indeed.

So i think the input box should simply expand down when another line is needed (only for string inputs, not lookups) and push the content down. And the box doesn't just stay extended while on input and then shrink and truncate text when the user leaves the field, it should just remain like that so the user can see his text while he is clicking the publish button or adding the language or whatever further information is necessary.

No, there is no codex component doing this, and as i saw in multiple forums this might not be trivial to achieve.

Google does this too

Should i adjust the ticket to fit this ideal scenario or should we look for another solution?

Hi @Lucas_Werkmeister_WMDE

this one i added with Upload File. Do you see it?

And the box doesn't just stay extended while on input and then shrink and truncate text when the user leaves the field, it should just remain like that so the user can see his text while he is clicking the publish button or adding the language or whatever further information is necessary.

AFAICT Codex TextArea with :autosize="true" behaves like this already (tested in the Codex docs after toggling the autosize prop manually).

In T414420#11557995, @Lucas_Werkmeister_WMDE wrote:

AFAICT a Codex TextArea with :autosize="true" and :rows="1" gets us most of the way there… but:

• It still shows up with a height of more than one row even when empty; we might have to update Codex to permit text areas that really look like text inputs until their value exceeds one line.
• We’ll need to prevent line breaks in the input.

One more thing:

• TextArea “allows manual resizing if needed” (docs), which we don’t actually want. I guess we’ll override the resize: vertical; rule via CSS.

In T414420#11814615, @Lucas_Werkmeister_WMDE wrote:

In T414420#11557995, @Lucas_Werkmeister_WMDE wrote:

AFAICT a Codex TextArea with :autosize="true" and :rows="1" gets us most of the way there… but:

• It still shows up with a height of more than one row even when empty; we might have to update Codex to permit text areas that really look like text inputs until their value exceeds one line.
• We’ll need to prevent line breaks in the input.

One more thing:

• TextArea “allows manual resizing if needed” (docs), which we don’t actually want. I guess we’ll override the resize: vertical; rule via CSS.

And another:

• The new “Maximum of 5 lines” requirement is not supported by Codex TextArea.

One more thing:

• TextArea “allows manual resizing if needed” (docs), which we don’t actually want. I guess we’ll override the resize: vertical; rule via CSS.

we really don't want that.

Change #1270994 had a related patch set uploaded (by Audrey Penven; author: Audrey Penven):

[mediawiki/extensions/Wikibase@master] [WIP] use CdxTextArea for inputs that might be long

https://gerrit.wikimedia.org/r/1270994

I was curious whether Codex's TextArea could be made to do what we want, and ended up with a WIP patch.

The two-line problem is solved by rows="1" and reverting the min-height styling that codex adds to the textarea.

I also learned that for existing multiline values, the default behavior of CdxTextArea does not set the initial size based on the text height. My patch includes some js that runs on mount to set the initial height, simliar to how the internal autosizing code works on input.

Not covered (yet):

• preventing line breaks
• enforcing a maximum of 5 lines

questions:

• Should we always prevent line breaks? Are there situations, like lines of poetry, for example, where line break support is helpful? desktop prevents line breaks both through preventing the enter key from doing anything and removing line breaks from pasted input. So yes, always prevent.
• Should all simple string datatypes get this multiline support? Or are there some that should keep the one-line-only CdxTextInput? If only some should get multiline, which ones?

In T414420#11820966, @AudreyPenven_WMDE wrote:

• Should we always prevent line breaks? Are there situations, like lines of poetry, for example, where line break support is helpful? desktop prevents line breaks both through preventing the enter key from doing anything and removing line breaks from pasted input. So yes, always prevent.

To add to this – the API quite strongly doesn’t support line breaks anyway. wbparsevalue strips them out

{
    "warnings": {
        "wbparsevalue": {
            "warnings": "The value passed for \"values\" contains invalid or non-normalized data. Textual data should be valid, NFC-normalized Unicode without C0 control characters other than HT (\\t), LF (\\n), and CR (\\r)."
        }
    },
    "results": [
        {
            "raw": "a b",
            "value": "a b",
            "type": "string"
        }
    ]
}

and wbsetclaimvalue prevents them

{
    "error": {
        "code": "modification-failed",
        "info": "String should not start or end with whitespace nor include vertical whitespace or tabs: test value",
        "messages": [
            {
                "name": "wikibase-validator-illegal-string-chars",
                "parameters": [
                    "test\nvalue"
                ],
                "html": "String should not start or end with whitespace nor include vertical whitespace or tabs: test\nvalue"
            }
        ],
        "(snip docref, servedby)"
    }
}

• Should all simple string datatypes get this multiline support? Or are there some that should keep the one-line-only CdxTextInput? If only some should get multiline, which ones?

I would go with all of them for now, unless Product or UX disagree.

@AudreyPenven_WMDE "Should all simple string datatypes get this multiline support?"

I am not entirely certain of what "simple string" means. These should not be included (but i am not sure if they are simple):
Tabular data
Geographic shape
Commons media

Musical Notation and Mathematical expression on the other hand, should for sure have this :) @AudreyPenven_WMDE

Change #1270994 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use CdxTextArea for string inputs

https://gerrit.wikimedia.org/r/1270994