質問

Setup: I am developing a PhoneGap/Cordova app for iOS and Android using jQuery Mobile. The app requires a calendar which I am creating myself due to the fact that an exhaustive search of plugins didn't yield any results that satisfied all my needs. I am using seven div's - one for each day of the week - which are all float:left'd and each is set to width:14.28571428571429% as this is 1/7 of 100%. I should mention that the calendar div container is set to width: 100%. Chrome developer tools also confirms that the container (id="calendar") is using 100% of the width real estate.

Problem: Everything looks and works great on the desktop, however once I start testing on my iPhone or iPad, a small margin (about 2%) appears to the right of the calendar.

Supporting Details: I have done quite a bit of research on this, and it appears that this is due to subpixel rendering. I read about Subpixel Rendering on WikiPedia and found this two year old article regarding the way different browsers handle fractions of pixels. It seems to me that 0.28[…]% is being chopped off in mobile Safari. The problem is, I don't know how to fix it. What confuses me even further, is that this appears to be a webkit issue, but the calendar renders just fine in desktop Chrome.

Code:

<div id="calendar">

    <div class="cal-week"> 

        <a href="javascript:monthPrev();">
            <div class="day day-inactive">28</div>
        </a>

        <a href="javascript:monthPrev();">
            <div class="day day-inactive">29</div>
        </a>

        <a href="javascript:monthPrev();">
            <div class="day day-inactive">30</div>
        </a>

        <a href="javascript:monthPrev();">
            <div class="day day-inactive">31</div>
        </a>

        <a href="javascript:selectDate(11,01,2012);">
            <div class="day">1</div>
        </a>

        <a href="javascript:selectDate(11,02,2012);">
            <div class="day">2</div>
        </a>

        <a href="javascript:selectDate(11,03,2012);">
            <div class="day">3</div>
        </a>

        <div class="clearfix"></div>
            <!-- fun fact: this is the first week of November, 2012 -->

    </div>

[&hellip;]

</div><!-- /calendar -->
役に立ちましたか?

解決 2

For anyone who stumbles on this:

After much (painful) searching through Webkit documentation, improper SubPixel handling is a well documented bug and needs to be fixed to make these types of issues go away permanently. The only sure work-around I can find is a negative pixel margin fix. This qusetion goes into some good detail on the matter.

In regards to my particular issue with seven columns, a negative pixel on each of the seven columns was creating a margin on the right-hand side of the screen. What fixed me was the idea of only applying the negative margins to every other column. So now columns 0, 2, 4, and 6 all have a margin-left: -1px and the other three do not. It works for now, let's hope they get to addressing this issue sooner rather than later.

Cheers.

他のヒント

I'm having a terrible time with something similar in Firefox, so maybe you can fit my fix to fit your need.

My problem is/was that I need to calculate screen width during a changePage, which on Firefox sometimes results in the scrollbar being substracted in the width calculation, so if I need width 1000px I'm getting 983px (sans 17px scrollbar).

It took forever to console the wrong value returned by Javascript. I'm now using this to fix:

wrapWidth = document.body.clientWidth,
// FIREFOX SCROLLBAR WIDTH FIX
// When caluclating the width of the screen Firefox includes 
// the scrollbar width although the page height is less 
// than available screen height. 
// Therefore page width is off by the toolbar width (17px).
// browser window: window.innerWidth  ~ e.g. 924
// wrapper page: document.body.clientWidth ~ e.g. 907

// if the page height is smaller than screen height, correct by 17px. 
fireFoxCorrection = ( window.innerWidth !== wrapWidth && wrap.height() <= window.innerHeight ) ? window.innerWidth-wrapWidth : 0,

This gives me 17px when the error occurs and 0 when it doesn't, so I can safely do

element_width = calculatedWidth + fireFoxCorrection

How about trying if you can pin the down the correction in your setup using window.innerWidth and document.body.clientWidth. If you could extract the difference, you could divide it by elements and add this as to the width of each element.

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top