Sat, Sep 22
Fri, Sep 21
Thu, Sep 20
Wed, Sep 19
@Bawolff A concern was raised in the team that this is potentially quite heavier than a relatively quick security fix; it involves some potential back-and-forth on how to handle the behavior.
thanks, @Niharika , this is super useful.
Tue, Sep 18
We should also include all development peripherals to the environment:
Mon, Sep 17
Fri, Sep 14
Thu, Sep 13
After the engineering discussion, it seems we have two main options, that depend on the focus of the feature set.
My personal opinion is that it's probably sufficient. If we consider screen readers to represent the state of whatever the user is focused on, then we need to make sure the name of the field is there, as well as its state. If we add the action-related text for fields you can add/remove and have a string saying the name of the field (with its state) for required field, that sounds like it would be a good descriptor.
Tue, Sep 11
Overall, the code looks good, but I have one concern that I think product/UX should consider (pinging @Niharika )
Sat, Sep 8
Fri, Sep 7
@Niharika there was a question raised during review by @Samwilson that requires your input: We've changed the titles/tooltips of the +/- field buttons, as per spec, but we also have "required" buttons that have the checkmark, and cannot be added or removed.
Thu, Sep 6
Whoops, it looks like we may have overlooked the focus when there are no fields. I opened this T203722: TemplateWizard: Only fallback to focus on 'add all' button if it actually exists to follow up.
One news item we might want to pay attention to is that Chrome is planning to disable scripts for what it deems are "slow connections" (2G) which might make our "no-JS" experience more relevant. See the news item on Chrome status: https://www.chromestatus.com/feature/4775088607985664
Yes, and we should do this concurrently with T202768: Decide the tech stack for the SVG Translate tool so we can set things up correctly.
We should explore using the data part of ULS for this, or, alternatively, at least as a first step, use ULS itself.
Wed, Sep 5
I added the 'focus on load' to this ticket, since it was a quick fix. Requires review.
Tue, Sep 4
Fri, Aug 31
The use of keyboard actions (once we're already on any button) is solved through this ticket T203287: TemplateWizard buttons (-/+ fields and 'add/remove all') do not activate on "enter"
Where should the focus be when you just load the template? I'd think it should be consistent, and focus the first available field (or 'add all' if no field is visible) but right now it has no useful focus until you start adding fields.
Thu, Aug 30
We have not yet made a decision, but we started a conversation about possible options.
Tue, Aug 28
Mon, Aug 27
Aug 24 2018
Aug 22 2018
Aug 21 2018
Aug 18 2018
I played around a bit (language'd stuff always pique my interest) and just a couple of quick comments that I've noticed:
Aug 16 2018
I ran an investigation to try and understand the impact of this, and what exactly happened. Here's the results (findings and recommendations at the end)
Aug 15 2018
@Hagarshilo wonderful work.
Aug 14 2018
Aug 9 2018
Aug 8 2018
Aug 7 2018
Let's try to see if there's a good way to test it once translations are in.
This was tested by running 'recheck' on this: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/GlobalPreferences/+/449375/
(extra job ran and passed)
@Samwilson I've merged and moved this to QA/Product -- I just realized, though, do you know of any template structure we could add to local wiki (or comm tech wiki if this is tested there) that can feature this field type, so it can be tested?
I went over the code, it looks okay to me; is there anything to actively QA or Product-chceck in this one?
@MusikAnimal It seems like it's mostly a prep-work for the actual feature -- should we close the ticket, or move to Product review?
@MaxSem this is already merged -- I see 'markasbot' and 'minoredit' in the options, but not edit tag (I may have missed it?)
Aug 6 2018
@MaxSem Now that the patches are merged -- are we missing anything to review/merge, or are we done with the quick way?
This task will not be done as part of GSoC after all; during development, it became clear that the development of a new asynchronous operation inside RCFilters is more complex than we'd realized, and would not fit in the scope of a GSoC summer project. Please see the update on the GSoC proposal task for more information.
Update on this project:
Aug 3 2018
I am wondering if the OOUI method may still be better here. It might not give us 100% what we want, but since it's used in so many other places, I have a bit more confidence in its stability...
Wait, sorry, I just realized something.
Yeah, <bdi> won't help if we're talking about <input> fields, I just saw the screenshots and thought we're working with spans.