I have a question regarding the SwiperJS plugin. It's being used on this website: https://overnieuw.nl/. On the corresponding homepage there is an element named "section_4__inner--left" which is fading in too late, as you can see if you scroll down the page. An element before named "section_1__inner--left" does fade in on the correct time.
Unfortunately I don't have a lot of experience with SwiperJS plugin yet, so I was wondering if someone encountered this kind of problem before and can tell me what to do?
Related
We are trying to build an music playing interface on a Vue page that plays in a bottom player as described here:
https://vuetifyjs.com/en/components/bottom-sheets/#music-player
But the playlist and other controls are in the main page. But the problem is that these elements get 'blocked' or deactivated or something, there is no way to interact with them. Just like in this example.
Input elements stop working and scrolling on the main page works only by grabbing the scrollbar on the side.
#clicks are still registered, however, and scrolling on some other components work.
I think I have tried every API setting and combination in the docs, like attaching it to different dom elements, or hide-overlay, and persistent, but nothing seems to work. The same principle seems to apply to other dialogs that take focus in vuetify.
https://vuetifyjs.com/en/api/v-bottom-sheet/
Does anyone have experience with this or know a workaround for it? It would be greatly appreciated!
This is intended behaviour. Your best bet is hide-overlay in combination with persistent
<v-bottom-sheet
hide-overlay
persistent
></v-bottom-sheet>
I face the same issue and solve that with the "retain-focus" property
try this <v-bottom-sheet :retain-focus="false"></v-bottom-sheet>
I've got a rather weird scenario going on here. I am trying to add tooltips to an existing ASP.Net MVC application in which I'm upgrading Bootstrap to 4.6.2. The upgrade was very smooth with no complications; I just want to replace the default display of titles with the nicer looking tooltips, but for some reason they're not appearing. I tried to simplify things by creating a new view to isolate the problem, and still no tooltip. I tried again with completely new solution, and wouldn't you know it, it works! So my question isn't "how do I create tooltips", but "how can I debug what's going on in the failing project?"
Here's what I've discovered so far. I believe you can see everything that's relevant in this screenshot of the nearly-empty view. All the included script files are there in the right order, my script is there, initializing the tooltip, and there are no messages in the console. When I hover over the link, a new <div> element is added to the DOM. In DevTools, I use the arrows to expand the tree, showing everything in the tooltip. The .fade:not(.show) CSS selector is the reason I don't see it. In the working solution, the show class is properly added to the tooltip's <div>.
So, could there be some setting in the existing application preventing the addition of the show class? Is something failing in the tooltip code,causing it to never add the show class without reporting errors? How should I continue debugging this? I tried stepping through the bootstap.js file, but being a JS noob, I'm getting a little lost. The screenshot is from Chrome, but I see the same behavior in Firefox.
This turned out to be one of those embarrassing oversights. My BundleConfig.cs file was still pointing to old Javascript files that were still hanging around after the upgrade. I should have seen it in the version numbers in the <script> tags.
I need to write a test script to validate that a button is present on the page and the button becomes sticky and stays attached at the bottom of the screen for mobile breakpoint.
I have already written a script where it resizes the browser window. However, How do i prove that a button remains sticky to the footer no matter how much scrolling user does.
Button retains its id and place in the DOM when its styling changes for the mobile view.
I need solution for all major browsers but if someone can guide me for Chrome that should be good enough.
I have looked into getComputedStyle but i think its bit messy. i am looking for more elegant solution using some library.
This check is baked in selenium - there's a webelement method isDisplayed() returning a boolean. Here's a link to the Java bindings - https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/WebElement.html#isDisplayed--
And if you're wandering if this is a "real" check is the element in the viewport, here's the webdriver's explanation how it's done - https://w3c.github.io/webdriver/#element-displayedness (in summary: yes, as much as this can be done).
I had a problem with the Masonry plugin causing to only function when the viewport is being changed, meaning the masonry boxes were invisible until you would resize the browser window. After that the boxes are not olny visible but also Masonry works as expected.
I resolved this problem by using regular CSS again for styling, and not LESS CSS anymore as I had intended.
But what would I be able to do to use both? (It doesn't seem like it's a simple 'reorder how the scripts are being loaded' kind of thing)
Funnily when I use jsFiddle and implement LESS CSS there, there is no problem. Maybe somebody can tell me what jsFiddle does to fix the issue?
https://jsfiddle.net/rcygo5fy/
code
"Solution": Since a solution would be a hassle with the code and compiling the CSS on every load is very heavy, especially client-side, the best solution is to leave LESS completely out of the end result and only use it for development but a LESS-to-CSS-rendered file for actual usage. With CSS the Masonry timing problem goes away.
I am trying to research about vue2 and wondering if there is any way that can make it easy to track if elements are visible on viewport or not so that we can do something like slide-in boxes when we scroll down the page. Any npm package or whatsoever that can be suggested? Thanks.
Currently using Vue-observe-visibility (https://github.com/Akryum/vue-observe-visibility) and have not stumbled on any issues yet.
The only thing to consider is that this only triggers when the element enters/exits the page by user scroll, not when it enters/exists because of DOM changes. Looks like it shouldn't be an issue for your use case, based on what you told about it.
Certainly check it out, it's easy to use!
vue-waypoint could be an option.
GitHub
NPM