(In reply to Alessandro Castellani (:aleca) from comment #3) > I'm not sure I agree with this. > If you're editing a pill it means you want to update the address you previously wrote. To you as the designer, yes. Are we currently offering any other way of inserting another recipient at the user's preferred position? Order of recipients does matter in real life... > I don't think we should allow adding multiple addresses in 1 pill, that doesn't make sense from a workflow point of view and we shouldn't enable this behaviour. Well, this bug is not exactly about "enabling" or "encouraging" that behaviour, but about error prevention, and handling predictable scenarios (more so as long as there are no other alternatives of getting the desired result). > It creates extra complexity for us to maintain and it's a paradigm I don't think we should introduce. Well, if we allow the user to type "2@foo.bar, x@foo.bar" inside a single pill in the first place (which may make perfect sense from their pov), you can't just discard legitimate input without warning. Either that, or just prevent entering more than one address into the pill. We know the syntax of a single address, isn't it? We need to work on refined address validation anyway, see bug 1609894. Btw, but just as a minor footnote, I guess we're still ignoring Bug 919953: RFC822 groups, i.e. named lists with concluding semicolon, e.g. |testlist: name1@foo.com, name2@bar.com;| > I would mark this as WONTFIX. I suggest that we re-evaluate this bug after you are done with bug 1601749 (drag n drop of pills), where you want to > allow manual reordering of pills within the same recipient container. There's no way of doing that without implementing at least half of bug 1603051 (Enable reordering and inserting of pills), i.e. to have inter-pill insertion points. After that, it'll make more sense to talk about this bug again, and I think we'd still have to do the error-prevention part one day.
Bug 1602442 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Alessandro Castellani (:aleca) from comment #3) > I'm not sure I agree with this. > If you're editing a pill it means you want to update the address you previously wrote. To you as the designer, yes. Are we currently offering any other way of inserting another recipient at the user's preferred position? Order of recipients does matter in real life... > I don't think we should allow adding multiple addresses in 1 pill, that doesn't make sense from a workflow point of view and we shouldn't enable this behaviour. Well, this bug is not exactly about "enabling" or "encouraging" that behaviour, but about error prevention, and handling predictable scenarios (more so as long as there are no other alternatives of getting the desired result). > It creates extra complexity for us to maintain and it's a paradigm I don't think we should introduce. Well, if we allow the user to type "2@foo.bar, x@foo.bar" inside a single pill in the first place (which may make perfect sense from their pov), you can't just discard legitimate input without warning. Either that, or just prevent entering more than one address into the pill. We know the syntax of a single address, isn't it? We need to work on refined address validation anyway, see bug 1609894. Btw, but just as a minor footnote, I guess we're still ignoring Bug 919953: RFC822 groups, i.e. named lists with concluding semicolon, e.g. |testlist: name1@foo.com, name2@bar.com;| > I would mark this as WONTFIX. I suggest that we re-evaluate this bug after you are done with bug 1601749 (drag n drop of pills), where you want to > allow manual reordering of pills within the same recipient container. There's no way of doing that without implementing at least half of bug 1603051 (Enable reordering and inserting of pills), i.e. to have inter-pill insertion points (as drop targets). The other half is making reordering keyboard-accessible. After that, it'll make more sense to talk about this bug again, and I think we'd still have to do the error-prevention part one day.