-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix(table): fix range selection #2865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #2865 +/- ##
==========================================
+ Coverage 86.76% 86.79% +0.02%
==========================================
Files 197 197
Lines 3280 3286 +6
Branches 965 968 +3
==========================================
+ Hits 2846 2852 +6
Misses 316 316
Partials 118 118
Continue to review full report at Codecov.
|
Going to be making a few minor adjustments to this later. |
@tmorehouse suggestion: decouple in two classes:
mixin-selectable.js:
_table.scss:
|
@lianee I've updated the classes, etc. |
Description of Pull Request:
Dynamically adds a class to apply
user-select: none;
when range selection is active.When table is selectable, it will have class
b-table-selectable
and one of the following three classes, depending on which mode is in use, on<table>
:b-table-select-single
b-table-select-multi
b-table-select-range
When at least one row is selected the class
b-table-selecting
will be active on<table>
.When
b-table-select-range
andb-table-selecting
are both active, the CSS ruleuser-select: none;
will apply to alltable > tbody > tr
rowsThis allows the user to select text within the table when a selection is not active.
Live preview https://deploy-preview-2865--bootstrap-vue.netlify.com/
CC/ @lianee
PR checklist:
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact:
The PR fulfills these requirements:
dev
branch, not themaster
branchfixes #xxxx[,#xxxx]
, where "xxxx" is the issue number)and adding a new feature, break them into separate PRs if at all possible.
Conventional Commits naming convention (i.e.
"fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos",
"chore: fix typo in docs", etc). This is very important, as the
CHANGELOG
is generatedfrom these messages.
If new features/enhancement/fixes are added or changed:
package.json
for slot andevent changes)
keyboard only users? clickable items should be in the tab index, etc)
If adding a new feature, or changing the functionality of an existing feature, the PR's
description above includes:
suggestion issue first and wait for approval before working on it)