vikunja/frontend
Archived
6
39
Fork 48
Code Issues 1 Pull Requests 4 Projects Releases 26 Activity

feat: hide quick add magic help behind a tooltip #3353

Merged
konrad merged 13 commits from feature/hide-quick-add-magic-help into main 2023-06-05 15:02:43 +00:00
Conversation 1 Commits 13 Files Changed 6 +8 -3
2 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit abb5128426 - Show all commits

3
src/components/tasks/partials/quick-add-magic.vue
View File

@ -107,10 +107,9 @@ const mode = ref(getQuickAddMagicMode())
const prefixes = computed(() => PREFIXES[mode.value])
</script>
<style scoped>
<style lang="scss" scoped>
.show-helper-text {
right: 0;
pointer-events: auto !important;
color: inherit !important;
}
</style>

8
src/styles/theme/form.scss
View File

@ -57,7 +57,7 @@
}
.field.has-addons .control .select select {
height: 100%;
height: 100%;
}
.control.has-icons-left .icon,
@ -103,3 +103,9 @@ h1, h2, h3 {
height: auto;
}
}
// Global style, because the rest of this styling is imported from bulma
dpschen commented 2023-04-12 18:13:09 +00:00
Outdated
Review
Copy Link

Define this in the component we actually need it. This way we don't have to move this style when we remove bulma.
Also: do we overwrite some styles here?

If not: couldn't we add a new class for these icons instead, where used?

Define this in the component we actually need it. This way we don't have to move this style when we remove bulma. Also: do we overwrite some styles here? If not: couldn't we add a new class for these icons instead, where used?
konrad commented 2023-04-14 13:58:16 +00:00
Outdated
Review
Copy Link

AFAIK we don't override these styles. We do use these classes in two places however, so that would mean we have to duplicate it if I put it where it's used?

AFAIK we don't override these styles. We do use these classes in two places however, so that would mean we have to duplicate it if I put it where it's used?
dpschen commented 2023-04-14 17:26:39 +00:00
Outdated
Review
Copy Link

I think that would be better. We do import $transition globally, so there is already a common link.

Another way could be to define the transition via a CSS-property, e.g. --form-icon-transition (and set the value via the $transition), so the dependancy is solved via DOM hierarchy. Since CSS-properties are scoped by their nature it's also not polluting some global namespace.

While having an animation on icons makes sense I would no like to increase of use of classes created by bulma. So if we want to change something I think it would be better to create new classes for these elements – even if they already have classes.

Maybe a way of thinking of it is similar to js-hook classes. Sometimes one uses classes like js_is-open where that prefix makes clear that the class was set during runtime (I saw that pattern mostly in context of vanilla dom libs in combo with SSR). So just imagine that all bulma classes have bulma- prefixed and these are all of bulmas namespace. In order to decrease / minimise our dependency on bulma, which is generally a good thing todo we should not use those classes to add our styles, but instead add new ones.

I think that would be better. We do import `$transition` globally, so there is already a common link. Another way could be to define the transition via a CSS-property, e.g. `--form-icon-transition` (and set the value via the `$transition`), so the dependancy is solved via DOM hierarchy. Since CSS-properties are scoped by their nature it's also not polluting some global namespace. While having an animation on icons makes sense I would no like to increase of use of classes created by bulma. So if we want to change something I think it would be better to create new classes for these elements – even if they already have classes. Maybe a way of thinking of it is similar to `js`-hook classes. Sometimes one uses classes like `js_is-open` where that prefix makes clear that the class was set during runtime (I saw that pattern mostly in context of vanilla dom libs in combo with SSR). So just imagine that all bulma classes have `bulma-` prefixed and these are all of bulmas namespace. In order to decrease / minimise our dependency on bulma, which is generally a good thing todo we should not use those classes to add our styles, but instead add new ones.
konrad commented 2023-04-14 19:26:02 +00:00
Outdated
Review
Copy Link

I've moved it to the components (duplicating it).

I would no like to increase of use of classes created by bulma.

That makes perfect sense. Ripping bulma out and replacing it with something else entirely is a whole separate project though, but it's a good idea to decrease our dependency on it, not increase it.

I've moved it to the components (duplicating it). > I would no like to increase of use of classes created by bulma. That makes perfect sense. Ripping bulma out and replacing it with something else entirely is a whole separate project though, but it's a good idea to decrease our dependency on it, not increase it.
.control.has-icons-left .icon,
.control.has-icons-right .icon {
transition: all $transition;
}