<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - UI: Improve handling of configuring table borders in table properties dialog (to make it work for multiple workflows)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143249#c29">Comment # 29</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - UI: Improve handling of configuring table borders in table properties dialog (to make it work for multiple workflows)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=143249">bug 143249</a> from <a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> <pre>(In reply to Telesto from <a href="show_bug.cgi?id=143249#c28">comment #28</a>) > It should be possible to put everything which isn't the same in tri-state > mode. This makes it complicated even further. Having a selection with different applied properties gives no advantage, only another state that user needs to be aware of. Also it destroys a "define then apply by selection" workflow, because every selection act would simply create such a heterogenous selection set; and only "select then define" workflow would be possible, with resetting individual controls from "undefined" to some value; and when user decides to add one more border to the set, every setting needs re-definition again. > Another topic which comes to mind: resetting all borders back to default. The *potential* (only needed when we implement true table borders) "reset to default" is easily implemented by the fourth radio button/drop-down: "reset to default" in addition to "none/visible/unchanged" mentioned in <a href="show_bug.cgi?id=143249#c26">comment 26</a>.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>