Thu, Apr 18
Wed, Apr 17
Apparently this healed itself (curtesy of minerva changes I assume).
if I change the de-label and somebody else changes the fr-label, I don't see the fr-label change, not even if I enter the editing mode for a second time. Only a hard refresh shows me the actual data
Tue, Apr 16
please find a screenshot of what chrome does by default in case of a sneak peek into alias editing. The aliases component has a blue border (as defined) because it has "focus within", the individual alias has the chrome default outline because it has actual focus. So far the individual alias focus style is not explicitly modeled. I advocate to a) explicitly model it [i.e. not leave it up to the browser] b) when modeling it to please consider the previous link.
Mon, Apr 15
@Jakob_WMDE you mentioned that you (quickly?) looked into this. If what I wrote makes sense then please feel free to move this task to done as there is no patch strictly connected to it - https://gerrit.wikimedia.org/r/503285 was created as bycatch but it is by no means representative of what the title of this ticket is about.
please find the following responses to the findings
one more question about the individual alias input element - given that the focus (blue border) is illustrated "one level up" from the individual alias (on the aliases), should the individual alias really not signal focus at all beyond containing the cursor? Outline comes to mind which, in some browsers (see chrome), is used with e.g. an orange color by default - depending on which browser they use, people may or may not be accustomed to it.
If there is no strong argument against it I'd like if we could - explicitly - add some visual indication. http://www.outlinenone.com/
Fri, Apr 12
Tried it on beta, looks ok given the feature set we expect to be in per the AC. Latest edits on Q11 were actually done using termbox.
The answer is: it's by design and not a problem. Using a v-show instead would avoid it but also cause significantly more mark-up sent through SSR without any added benefit and potentially causing other problems (we tried that before and TermTextField struggeled to resizeTextField() on initially hidden textareas, i.e. when first opened the textareas were all tiny).
Thu, Apr 11
Wed, Apr 10
TIL https://caniuse.com/#feat=css-focus-within (at only 80% unfortunately)
@Matthias_Geisler_WMDE said: "if you need more than one line you are doing it wrong", i.e. either 1 Vue.set() to add an individual property or 1 use of the spread operator to add a bunch of them.
Thanks, @Hanna_Petruschat_WMDE - fixed the description accordingly.
@Hanna_Petruschat_WMDE Thank you for the very precise task definition. One question to be sure: the current wikidata termbox does not replace newlines with "a space" but with an empty string. Is this change in behavior intended?
This was originally created as a subtask of T216987 but it turned out there is a dedicated story for addressing these challenges: T217000 - so it became a task of that, ready to be picked along with it.
Tue, Apr 9
@Jakob_WMDE Adding overflow: auto ensures that scroll bars are not shown - while, by default, they are visible for reasons.
Mon, Apr 8
We just happened to find this again, realizing that placeholders are indeed not a task inside of T216987. Are we sure this is in the right place in "in preparation"?