Here's the site:
http://philly.thedrinknation.com/mobile
On smartphones, the screen is too wide - allowing you to scroll to the right a little bit, rather than being exact fit.
On a desktop you can reproduce this in FF, make your browser about 350 px wide, then use the keyboard arrows to scroll right.
I have narrowed this down to the javascript from sharethis:
http://w.sharethis.com/button/buttons.js
If I take out that call, the page is fine. Add it back in (even on pages not using the widget), and the scrolling comes back.
It looks like they modified their code back in March, and I'm guessing that might be related. I asked them about it, but so far no response.
Can anyone give me pointers on debugging this further? I will copy the .js file locally to edit it if need be, but so far I can't see what is causing the problem.
Strictly speaking, your issue isn't caused by javascript. Rather, it's caused by styles that AddThis is using. The #stwrapper element used by AddThis has an explicit width of 354px that is causing your issue. The problem is caused by this css coming in an AddThis stylesheet (hosted by them):
.stwrapper {
position: absolute;
width: 354px; /* This is causing the issue. The width of this element ensures that the page can never be smaller than 354px */
z-index: 1000000;
margin: 0;
padding: 0;
top: 0;
left: 0;
visibility: hidden;
height: auto;
}
As this stylesheet is coming from AddThis and you don't have control over it, you need to override the styles in your own stylesheet while ensuring that AddThis still works as intended.
I can't see where you're actually using AddThis, so it's hard for me to suggest what style adjustment you should make that will fix the width issue and keep AddThis working, but something like the following would be a good start:
.stwrapper {
width:auto;
}
Related
Everything works fine on any desktop browsers. Regarding mobile browsers, I’m having a really weird issue with Chrome on iOS only.
First load of the website from the URL bar works well, viewport height is correct. However, if I open the same site from the history or bookmarks, the viewport height is wrong and doesn’t take into account the real viewport.
Here is the basic style css I use:
body, html {
height: 100%;
}
Below part of the code I used before:
body {
margin: 0;
padding: 0;
overflow-x: hidden;
min-width: 320px;
background: #fff;
}
Here is the capture of the first load, there is not scroll bar and height viewport is correct:
Here is the capture on the second load of the page from the history, height is different and the page is scrollable:
Here are the logs, we can see that the height is different from the first load to the second load:
I’m not sure if I’m missing something but I disabled as much as possible my code, cleared the cache of the browser etc. but the issue persist. It happens on various iPhone models too.
Edit 12/20/2020
Here is a similar issue on a react website: https://www.kirupa.com/react/examples/react_router/index.html#/
If open via the link, viewport is correct. Reopening this website from the history, it will have a different height and a scroll bar will appear.
Thanks!
Try using
margin:0;
padding:0;
box-sizing:border-box;
}
And remove the display for html.
I have tried to make my site tokyocomedy.com to be responsive design down to a minimum of 320 pixels wide. Most, if not all, pages, such as this top page look reasonably good down to that size, using Firefox's responsive design view:
However, this one page, the schedule page, is not working:
The width it gets stuck at seems to be around 530 pixels:
The only thing that is different on this page is the calendar, so I could be wrong, but my best guess is that something about the calendar CSS or JavaScript is holding some minimum width or padding space or something. I have gone through all the elements I can find using the Firefox web developer inspector:
Relevant CSS IDs and classes seem to be #calendar, fc-toolbar, fc-header-toolbar, fc-view-container, fc-view, fc-list-month-view, fc-widget-content, and fc-widget-header. However, I can't find any width declarations, padding, margins, or any other sizing declaration that would explain why the page will not shrink horizontally. It's possible that maybe there is JavaScript acting on the styling that is altering it in a way that is less easy to find.
The page uses the fullcalendar v3.9.0 JavaScript library. I've put the CSS in use on PasteBin for reference.
What is preventing this calendar page from shrinking down to 320 pixels like other pages on the site?
There is a small error in your code. You need to use word-break css property here as your email text is big. kindly refer to attached screenshot.
Hope it solves your problem.
please add below two property and check
* {
box-sizing: border-box;
}
#maincontent {
float: left;
width: 100%;
}
You used display:inline-block style.css line no. 60 ,use display:block rather than display: inline-block
#maincontent, #upcomingshows, #recentblog{
display:block;
vertical-align: top;
}
I have a header with position:fixed and I'm trying to implement amp-sidebar component.
AMP is creating the -amp-fixedLayer adding style="top: calc(0px); pointer-events: initial; z-index: 10000;"
to fix scrolling performance in Safari ("[FixedLayer]" "In order to improve scrolling performance in Safari, we now move the element to a fixed positioning layer:" )
The problem is that since amp-sidebar component has a z-index:9999!important in their styles, the fixedLayer is displayed in top of the sidebar.
I thought about wrapping amp-sidebar and then I could add the z-index I want, but the parent tag for an amp-sidebar can only be 'body'
Any ideas how to fix this?
I just had the same issue and after fiddling a bit I found a way to edit the Z-index of my header.
Amp puts what z-index it thinks is needed but you can tweak those values. For instance:
header {
position: fixed;
z-index: -2000;
width: 100%;
background-color: black;
opacity: 0.7;
color: white;
}
This is the CSS code of my header, the trick here is to use a negative z-index. Amp will take its default value, add the z-index from the style (negative in this case) and put the result in the CSS.
So in my case the calculated z-index of the header is less than the sidebar's and therefore the sidebar gets on top of the header.
Hope this helps.
Fairly limited options
Considering that a portion of the intent behind amp is to push developers toward a UI standard (where the sidebar should always take the entire height of the window), you'll have to lightly break it.
note: Apparently jQuery is not an option.
Use margin on the sidebar
amp-sidebar {
margin-top: 10em;
margin-left: 5vw;
}
Ultimately, submit a bug report here:
https://github.com/ampproject/amp-by-example/issues/new
Roll your own amp
Submit a bug
Fork the github repo.
Patch the bug by setting the sidebar z-index higher.
Use your patched repo.
Submit a pull request to the master amp repo (fixes bug you reported).
That's really the right way to handle these scenarios.
How do you disable horizontal scrolling on a webpage?
I understand that this question has been asked many times before on stackoverflow (here, for example).
The most common answer says use CSS to set overflow-x: hidden; or max-width:100% for the html/body elements. However, these seem to hide the scrollbar but still allow the user to scroll with middle clicks, trackpad swiping, and touchscreen swiping. I'm looking for a solution that allows NO horizontal scrolling of any form.
The next most common answer says don't make your content wider than the screen. Maybe this is a good answer, but in general it's not very helpful and in my particular situation I don't know how to make my content fit.
Are there better methods for preventing horizontal scrolling?
To give you an idea of the problem that's motivating my question, take a look at http://www.tedsanders.com/BetTheBill/. So that you can see the problem better, I have highlighted the offending svg element in gray. When you click the green 'Bet The Bill' button, the svg rotates. If your window is small, the corners of the gray rectangle sometimes end up pointing off the screen and make horizontal scrolling possible.
I've tested this issue on the current versions of Chrome, Android Chrome, Firefox, and IE11. Only IE11 gives the behavior I want, with no horizontal scrolling.
Edit: Thanks to your helpful answers, I now have a solution. I'm going to implement it soon, but unfortunately that means my link above, originally meant to illustrate the problem, will no longer illustrate the problem. Sorry to all future visitors! (Perhaps in hindsight I should have made a fiddle. Although who knows how long that will even last...)
Edit2: Beware, the javascript solution below does not necessarily work on mobile browsers (in my version of Android Chrome there is significant jitter).
Edit3: Aha! My friend told me that overflow: hidden; will indeed work, but it needs to applied to the parent div and not the body or html or another ancestor. This looks like the best solution!
Try this:
html {
overflow-x: hidden;
width: 100%;
}
body {
overflow-x: hidden;
width: 100%
}
I believe overflow-x: hidden; will only stop the particular element that it is applied to from scrolling, so outer-more elements can still cause the window to scroll. Applying it to html and body should prevent anything which exceeds the width and height of window from causing the window to scroll.
Adding width: 100%; will force the html and body tags to be exactly 100% the width of the window.
But in your example that's not the problem. For some reason the <div class="container"> sometimes displays another set of scrollbars just for the container and the scrollbars appearing and disappearing is what causes the container's movement.
You can fix it by adding to following:
/* overflow: hidden; stops the second set of scrollbars */
/* I increased the width by 300px and added 150px padding on either side. This stopped the grey background from disappearing when the pie chart rotated. */
.container {
overflow: hidden;
width: 930px;
padding-left: 150px;
padding-right: 150px;
}
var offset = window.pageXOffset;
$(window).scroll(function () {
if(offset != window.pageXOffset)
window.scrollTo(0, window.pageYOffset);
});
Also do not forget to hide overflow.
Aha! My friend gave me an answer so I came back here to post it for all of you. overflow: hidden; will indeed work, if it is applied to the parent div and not the body or html or another ancestor. And unlike the javascript solution kindly provided by user3796431, it even works on mobile.
I have a simple JSFiddle of a single floating header here:
http://jsfiddle.net/zT9KQ/
Basically, this uses translate3d to kick in the GPU and hardware accelerate the floating header so that it may be drawn more smoothly. The header jitters in the latest Safari but gets drawn perfectly fine in the latest Chrome, FF and Opera. The actual code that is being affected by this (the code that spurred this question) is code I've written that cannot be shared publicly but works in a similar manner where fixed positioning is, unfortunately, not a valid solution.
I have tried:
Setting the backface-visibility CSS property to none.
Setting the perspective CSS property to 1000.
Playing with requestAnimationFrame during the animation logic.
Throttling the scroll event callback.
Setting the translateZ transform to something higher than 0px.
But none of this has worked (or at least - it seems reasonable to assume the GPU has kicked in but the jittering persists). I noticed that two questions are already open that are identical this one I'm raising but no one has answered them:
Jitter in Sticky Header in Safari
Implementing fixed position in javascript causes jitter in Safari when scrolling
Is this a known bug? Is there a performance hole I'm not sealing up?
EDIT
I have been receiving a lot of questions as to why position: fixed is not a valid option. To directly reply to Antony's comment on the question itself:
I'm not emulating/reinventing position: fixed. If you look at the top-voted answer (as of this comment), you will see that this seems to be a Safari issue. The reason position: fixed is undesirable in this case is because the code in question must be able to support multiple floating headers that sit below each other and have a "container" range where there may be infinitely nested containers. Using fixed positioning not only makes the code more complicated in the case where these floating headers live in a container that horizontally scrolls but also makes the component more brittle overall (calculating offsets when the widget needs to sit within another container somewhere else on the page). So, semantically, absolute positioning fits my needs better than fixed.
SECOND EDIT
Upon thinking about what Antony had been telling me (that I may be reinventing the wheel), and after hearing about -wekbit-sticky from user3716477, I would like to update the question to show what I'm trying to do. You can see how my code behaves in every browser other than Safari here:
http://cl.ly/3y1i3C473G2G
I have learned:
You cannot rely on the scroll or really any scroll-like events (such as mousewheel) since they are asynchronous in nature. I submitted a bug to Apple detailing what was happening and they closed the bug for this reason.
There is no real way to do what I want as of now - to have multiple floating headers that stack and replace each other. I guess I'll have to wait for something like -webkit-sticky to come out.
I should include all relevant information in SO questions from here on out. :-P
Thanks for playing guys! Here's the exact response I received from Apple:
Apple Developer Relations09-Jun-2014 01:16 PM
Engineering has determined that there are no plans to address this
based on the following:
Code is using scroll events, which are asynchronous.
We are now closing this bug report.
If you have questions regarding the resolution of this issue, please
update your bug report with that information.
Please be sure to regularly check new Apple releases for any updates
that might affect this issue.
Since there is an apparent delay between scrolling with the trackpad and the scroll event firing, you can attach the handler to an additional mousewheel event to smoothen things up.
$scrollContainer.on('scroll mousewheel', function () {
// reinvent the wheel here
});
You can see in this demo here that jittering is far less likely to occur when you scroll with the trackpad. In the demo, I have invoked the handler on load to eliminate the flash when you first scroll on Safari. There may still be some occasional jitter, but if you want to minimize that, you can go the resource intensive way of using setInterval and requestAnimationFrame.
This might fix the problem for now, but as I have said before, this emulation approach is not ideal and you are very likely to run into more trouble down the road.
It appears to be a bug with Safari scrolling. If you drag the scrollbar manually (don't use the trackpad gesture to scroll), then there is no jittering.
Chrome (and other browsers) handle scrolling differently which is why this bug is only present on Safari. You might want to submit a bug report to Apple.
How about a little restructuring, like this:
http://jsfiddle.net/me2loveit2/zT9KQ/6/
html:
<div>
<h1>Header</h1>
<div class="container">
<div class="content"></div>
</div>
</div>
CSS:
.container {
height: 300px;
position: relative;
overflow-y:scroll;
}
.content {
height:1000px;
}
h1 {
position: relative;
top:0px;
left:0px;
margin: 0;
width: 100%;
background: black;
color: white;
}
If you are using something similar to the jiddle code you have to check if browser is safari and then make it a different way like:
$(function () {
var $header = $('h1'),
$container = $('.container'),
$scrollContainer = $('.scroll-container'),
scrollContainerOffset = $scrollContainer.offset().top;
$scrollContainer.on('scroll', function () {
var top = Math.max(0, $container.offset().top * -1 + scrollContainerOffset);
$header.css('top', top + 'px');
});
});
Even when it isn't the way you want your problem to be solved, it might be a workaround that may help...
Scroll events are sent asynchronously in various browsers; you should not rely on them to do things like this.
The best solution would be to use position:-webkit-sticky; top: 0;
You could try and disable all and any javascript-ish scroll handling and just simply remove
position: relative; from the .container.
Afterwards just add h1{ top:0; } and it will happily stick to the .scroll-container.
Excerpt from CSS absolute positioning:
Position it at a specified position relative to its closest positioned ancestor...
To explain - your absolute H1 will look up the tree for the first ancestor element which defines a "position" property and inherit it as a 0,0 reference point.
It could be a WTF at first, but this behaviour is a powerhouse once you tame it.
EDIT: Related to the original jsFiddle, I made some more property removals:
http://jsfiddle.net/253Ss/
^ .container wrapper could be removed as well, since it is no more neccessary in a technical sense.