[wp-trac] [WordPress Trac] #11302: Bulk editing posts should pre-fill fields with the same value / allow for removal

[WordPress Trac]

#11302: Bulk editing posts should pre-fill fields with the same value / allow for
removal
-----------------------------+-----------------------------
 Reporter:  pavelevap        |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Quick/Bulk Edit  |     Version:  2.9
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:
-----------------------------+-----------------------------

Comment (by dmsnell):

 After some conversations today I stumbled upon this ticket after thinking,
 "if the ability to bulk-remove categories isn't in WordPress already it
 ''must'' have some challenging long-term issues." Turns out I was right!
 Anyway I'd love to try and eye this ticket for Contributor Day at WordCamp
 US 2017 and on that hope would love to get some conversation/feedback
 started here so I can prepare for it.

 Since it's been four years since issues with browser compatibility for
 ''indeterminate'' checkboxes was discussed I decided to look it up: all
 major browsers should support the tri-state box but it's still not
 possible to indicate that indeterminate state with HTML only - one must
 use JavaScript.

 https://html.spec.whatwg.org/multipage/input.html#dom-input-indeterminate

 '''Question one''' is how we feel about the tri-state checkbox in general.
 Is it the right idiom? I wasn't sure if the indeterminate state should
 imply that the category should be removed or if it would mean we aren't
 intending on changing the category. My conclusion was that unchecked
 should imply removing the category, checked should imply adding the
 category, and indeterminate should imply not changing anything.

 Maybe on account of this confusion I had a hard time seeing the tri-state
 actually solving our wants. It's almost as if we need something else in
 addition to the checkbox.

 '''Question two''' is how important it is to us that this all work without
 JavaScript. I believe that we should be able to figure out how to make
 this all work with the appropriate scripting before submitting the form,
 but does the form have to be able to work without it? The list of posts to
 the left of the category box appears to already rely on JavaScript for its
 functioning.

 '''Question three''' is maybe less important for discussion because we can
 always "make it work" but how should we represent this on the API side. My
 guess is that we can probably add some new "categories to remove"
 attribute in the request.

 ----

 It was hard for me to think up examples of existing UI for this purpose.
 LightRoom doesn't use checkboxes: they have tag names, tag names with a
 star at the end, and the absence of tag names to indicate "all items have
 this tag," "some items have this tag," and "no items have this [non-
 visible] tag." It doesn't list all of the available tags either, which is
 a bit simpler than our category bulk edit box.

 After some doodling I came up with an idea which would indicate both the
 addition or not of a category as well as its removal: a hoverable `x` to
 the left of the checkmark. The video below is crude and a prototype and is
 only there for the idea. The picture shows one way we might be able to
 indicate that a category is on the removal list.

 [[Image(https://cldup.com/TMlmeM2_WU.gif)]]
 [[Image(https://cldup.com/ZYUaFYRQQ3.png)]]

 ----

 This makes me wonder too if a radio button isn't technically more
 appropriate. Of course the styling would need to be made nice but I think
 we're truly dealing with a tai-state field: add to all, remove from all,
 or leave them all as they are.

 Could we style a radio button in a way that communicates these states the
 way we want?

 Anyway, thanks to all who provide feedback here. Once I have a better idea
 of what we would want to build I can work on creating a patch.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/11302#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform