i’d guess the iPhone has more advanced “site-area” recognition routines and also knows about common patterns “in the wild”, especially stuff that’s not at all intuitive about the CSS box model.

at 98%, the whole text fits on my phone screen (800×480). i can still scroll though, but that’s only by a few pixels (borders). i don’t know what the width attribute would accomplish here, but i can only talk about android and Firefox, not any of the other popular browsers like IE/safari/opera.

I test on an iphone and the iphone doesn’t have the horizontal scrolling problem with width of 100%. I saw it previously on firefox and safari. Since Android’s html engine is the same as the iphone (webkit) it never occurred to me that it would be a problem.

removing that directive still solves the issue, but my explanation was wrong.

the width property isn’t inherited. rather, it’s an issue with the box model, it seems. see http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug for details.

#story is set to 100%, but it also has padding:8pt. 100% plus padding is wider than the screen.

#story, #top-header, #bott-header

{

width: 100%;

}

i think that’s the problem. this directive not only applies to div#story, but it is also inherited by all its children (H2 and Ps).

so the children are 100% wide, and the div#story has padding, so the div#story has to be wider than 100%.

i can observe the “over-wide” issue on firefox too, now that i set it to the storiesiphone.css style.

indeed, using the web developer plugin and removing that 100% directive solves the issue at least in firefox.

If you click on ‘Settings’ in the new stories page, and from the screen size menu, select small, save, then load a story, the site will deliver the mobile stylesheet.

I’m guessing that /bit/stories.css retrieved with chrome on my desktop (win7) is NOT the small-screen/mobile CSS, right?

How could I view (and play with) the small-screen site version on a desktop?

I checked the file, and I couldn’t find a problem with it. I opened it with stanza on the Mac, on the iPhone and with Calibre on the Mac and it opened in all cases. Just in case, I forced the system to recreate the ePub file. Try downloading it again, just in case the first time there was some transmission errors that caused a corruption.

The one exception that I seem to have found so far is, for some reason, MWTB’s “Growing Up a Master”. Three other stories of his work fine as an ePub and I can read them without problem. However, when I try to access the GUaM story, either on my Reader or on my PC’s reader, that particular ePub file crashes the reader program. What is even more annoying is that, if I try to manually put GUaM onto my Reader, then when I reach that story while scrolling through the list of titles on my Reader, the Reader suddenly blanks the screen and resets itself.

I made some minor changes to the ‘body’ tag stylesheet. Let me know if it helps.

i have to scroll every chapter page horizontally to see the clipped text (just a few characters) on the right.

it looks like the text area is the right size (i.e., 100.0% of whatever my screen width happens to be), but the margin is added to that.

might that be tweaked somehow?

Unfortunately, the Kindle doesn’t support cookies. So you can’t log into the site with it.

Anyone successfully accessed the site using kindle before?

I suspect (without any proof)that your server is set to save bandwith and bzip all data it can when sending to browser, and poor ol’ .txt file is the victim of it.

That said, I haven’t REALLY put time in to trying to solve the problem. If there’s any changes, I’ll let you know.

Please move the line for the update next to the the date of first posting, the way it is shown now is irritating.

I do not have an I-pod or similar, so no comment.