Building for mobile is challenging. Building widgets is challenging. Building widgets for mobile is especially challenging. Since the release of Tint ten months ago, we’ve iterated our widget loading strategy a number of times. First, we started out with a straight iframe embed that we put on our first customer’s sites. That’s when we realized our first mistake: assuming that iframes work in every browser. It turns out that mobile browsers have serious differences with desktop browsers in rendering iframes. Below is a description of how iframes are handled on each platform, and the strategies we use to make sure things render correctly:
How iframes load on desktop, iOS, and Android
Link to the fiddle
- Desktop: Iframes are constrained by their defined height and width. Any overflow is contained using scrollbars.
- Android: Iframes are NOT constrained by any defined height and width, like iOS, however, the “webkit-overflow-scroll” property does not work for the Android browser. Thus, the container div just cuts off the iframe’s overflow content. To get around this, we created an auto-extend feature for our widget which reverses the dimension communication so that the widget sends messages to the parent page to tell it what size the container div should be. That way, the container div sizes correctly to the iframe, so that at least there is no clipping of widget content.
Performance on Mobile
<script> tag uses the “async” flag so that browsers do not block other items on the page due to our script (which can take longer to load due to latency, even with a CDN)
- Our widget loads fewer posts than our desktop widget to reduce the number of image requests that need to be made on render.
- We test our widget on mobitest.com to make sure our waterfall chart stays as short as possible