I am building a slide menu.
The menu is long and I need to be able to scroll inside of it, so I have set overflow-y: scroll on it.
I am using -webkit-transform (and variants on other browsers) as the transition property.
Now I can't scroll inside the div, using the scrollwheel when on top of the div will make the whole page scroll.
If I change the menu's behavior and transition the right property (setting the menu to right: -320px and animating it back to right: 0), the scroll works.
This bug only happends in Safari, it works fine in Chrome and other browsers. Also works on iOS.
Anybody know a workaround? Anyone experienced this issue before? I can't seem to find any info on it. Thank you.
I had the same issue with the difference that I use an animation instead of a transition and overflow: auto instead of overflow: scroll.
This fixed the issue for me (el is the DOM element to which the animation is applied):
function fixSafariScrolling(event) {
event.target.style.overflowY = 'hidden';
setTimeout(function () { event.target.style.overflowY = 'auto'; });
}
el.addEventListener('webkitAnimationEnd', fixSafariScrolling);
Related
I want to disable sticky toolbar which appears on top of page when page is scrolled. How it can be done ?
I resolve this problem by CSS
.ck.ck-editor__top.ck-reset_all {
z-index: var(--ck-z-modal);
position: sticky;
top: 0;
}
.ck.ck-sticky-panel__placeholder {
display : none !important;
}
.ck.ck-sticky-panel .ck-sticky-panel__content_sticky {
position: unset;
}
The fact that the toolbar appears in the wrong place when the editor is in an overflowed container is a bug that we are aware of. But in this case, I'd recommend you to not use the classic editor at all. If you want to have more control over where the toolbar goes, e.g. the DecoupledEditor (demo) allow controlling the toolbar. This editor type doesn't do anything with the toolbar itself – it just creates it and it's up to you where you're gonna insert it.
Another option would be implementing your own custom editor, but that'd be necessary only if you wanted to make even more customizations
I'm having same issue with the classic-editor, the position of the .sticky_panel is changing on the event of focus in the .editor_editable.
at some point when it's not visible within the display and click inside it goes all up to first element .
CSS only:
ck.ck-sticky-panel .ck-sticky-panel__content_sticky {
position: absolute !important;
}
In my editor build, I did a hack like this:
const stickyUpdateInterval = setInterval(() => {
editor.ui.view.stickyPanel['_checkIfShouldBeSticky']();
}, 100);
editor.on('destroy', () => {
clearInterval(stickyUpdateInterval);
});
This is just a crude hack that will update sticky balloon all the time.
If you know exactly in which overflow container your editor will be mounted, you can do something more clever, like listen to scroll events and update only then (this is what CKEditor is doing for the window, BTW, that's why it's not working when you put it in a container).
I have spent some time trying to get the CKEditor Classic component "sticky toolbar" to work nicely in Angular with a scrolling pane and there are 2 issues I had to overcome.
The position of the toolbar when sticky this defaults to the top
of the browser page (view port) - so (in Angular) you need to
configure this setting in the HTML template :
[config]="{ui:{viewportOffset:{ top: 58, right: 0, bottom: 0, left:
0}}}"
Making the editor respond to scrolling. This was a more difficult
one to resolve for me. The solution I have is (thanks to panta82
above) is to catch the scroll events and call a function in the
editor to check if the toolbar should be sticky or not .. it's
called checkIfShouldBeSticky :)
Here is a working sample in StackBlitz
I faced the same issue,
if you have header then below css will also help
#media only screen and (max-width: 767px) {
.ck-sticky-panel__content {
top: 180px !important;
}
}
#media only screen and (min-width: 768px) {
.ck-sticky-panel__content {
top: 128px !important;
}
}
document.getElementById('main')?.addEventListener('scroll', () => {
setTimeout(() => {
// eslint-disable-next-line no-underscore-dangle
editor.ui.view.stickyPanel._checkIfShouldBeSticky()
}, 100)
})
I am making a simple fixed SoMe sharing button set for a blog. Everything is fine and dandy except in Safari. Hovering over one of the buttons changes the background-color of the siblings to a color I do not specify anywhere in my CSS. This behavior goes away as soon as I change the wrapper from fixed to relative/static/absolute.
Has anyone ever run into this?
Am I doing something wrong?
If not, is there a hack/fix/workaround?
HTML:
<div id="share-links">
<a class="share-twitter" href="#">a</a>
<a class="share-facebook"href="#">a</a>
<a class="share-linkedin" href="#">a</a>
</div>
CSS:
#share-links{
left:0;
top:5em;
position:fixed;
}
#share-links a{
display:block;
height:2em;
width:2em;
color:white;
background-color:#a16159;
}
#share-links a:hover{
background-color:#8a392e;
}
Fiddle: https://jsfiddle.net/u6vzq192/26/
I discovered this problem in a slightly different situation. I have pagination dots in a fixed div using links like you have set up. I am adding a class to the links with Javascript which in turn changes the background color. Every time this happens the background colors of all the other links go crazy. I believe that it is a rendering bug in Safari inverting the background of the links when one changes.
After much experimentation with your example I discovered that it stops if either the links themselves are much larger or the container is much larger. Since setting the links to be giant buttons affects design, it seems the best solution is to set the container to be larger. Since your example is a vertical set of links you would set the height of the container to be something much larger than the links. I used height: 100%; but a large px should work too. If you had links laid out horizontally you might need to make that width: 100%; instead.
CSS:
#share-links{
left:0;
top:5em;
position:fixed;
height: 100%;
}
#share-links a{
display:block;
height:2em;
width:2em;
color:white;
background-color:#a16159;
}
#share-links a:hover{
background-color:#8a392e;
}
I encountered a similar problem. As well as being fixed, one of the inside elements had transform:rotate 90 deg and had a hover effect that changed its position slightly (pulled out from the side of the screen). The background color of this element and its sibling were the same, and both would flicker randomly when elements on the page were changed / rendered.
I finally found a combination of styles that stopped the background colour flickering altogether.
I added the following to the parent element from here: https://stackoverflow.com/a/27863860/6260201
-webkit-transform:translate3d(0,0,0);
-webkit-transform-style: preserve-3d;
That stopped the flickering of the transformed/sliding element.
And I added the following to the remaining element from here: https://stackoverflow.com/a/19817217/6260201
-webkit-backface-visibility: hidden;
This then stopped the flickering of the background colour for the sibling element.
I am experiencing elements transition misbehaviour into my page, IE(11) only;
The fullscreen revolution slider, remain in place doesn't move with the wrapper when the left slider is opening (clicking on info+ button like we have in Chrome/Firefox). Thanks to #afelixj, I've tried to use this css hack for IE in order to apply the tansition effect to the fullscreen slider too, adding .fullscreen-container but without result.
#media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
.header, #bar-left, .fullscreen-container{
left: 0;
transition: all .5s;
}
.shiftnav-open .header, .shiftnav-open #bar-left, .shiftnav-open .fullscreen-container{
left:590px;
}
}
For comparation, please open this page in IE11 and Chrome and open/close the left slider using the info+ button.Live link here
Other non fullscreen rev sliders pages work fine using the left slider open/close in IE11/Chrome.
live link here.
Any thoughts?
LE: also I've tried to aaply to the #wrapper or .shiftnav-wrapper:
#media screen and (-ms-high-contrast: active), (-ms-high-contrast: none) {
#wrapper{
left: 0;
transition: all .5s;
}
.shiftnav-open #wrapper{
left:590px;
}
}
(In this second test, the result looks ok in fullscreen rev slider pages but if I open a non-fullscreen rev slider page, the content will be shifted with +590px over 590px. when the left slider is open).
Instead of the .fullscreen-container, can you try to apply the style to .forcefullwidth_wrapper_tp_banner class?
I have a Rally.ui.cardboard.CardBoard as an item in an Ext.tab.Panel. When there are enough cards to cause a vertical scrollbar to appear, eating 16px of width, instead of fitting the new width dynamically, a horizontal scrollbar appears too. This doesn't happen when the CardBoard is rendered to document.body.
I've been looking for the right set of config options to make the TabPanel and its child items[] resize automatically. After two days trying in vain, I'm about to give up and just force a width of 1902px for PCs and 2862px for Macs. If anyone has a better idea, I'm more than willing to try it... anything at this point.
We could find no way to do this through config options alone, so we ended up listening to the App's own resize event and updated the panel size. In the App config we have this, and it does the trick:
listeners: {
resize: function( app, width, height, oldWidth, oldHeight, eOpts ) {
if (app.TabPanel) {
app.TabPanel.setWidth(window.innerWidth);
app.TabPanel.setHeight(window.innerHeight);
}
}
}
If anyone has a better solution that only uses config options and the framework does the resizing, I'd still like to see it, as the above is an ugly hack even if it works.
html {overflow-y:
scroll;height:101%;overflow-y:hidden;}
To force scrolling, when I view one my sites on my Mobile phone the bottom gets cut off, but looks fine in FirefoxF/IE.
Any ideas?
It should be enough to say:
html { overflow-y: scroll; }
but I would also try
body { overflow-y: scroll; }
The overflow-y:hidden; would clip the contents that exceed the size of the element. The default should be automatic to allow scrolling but setting it to overflow-y:scroll; or overflow:scroll; (which would allow vertical and horizontal scrolling) should make it work.