Source code line numbers and the iPhone

Web standards were supposed to free us from the hassles of browser-specific code, but odd corners of incompatibility still exist. The syntax highlighting and line numbering code I added to the blog last week works perfectly in Safari, Chrome, and Firefox (and probably even on Internet Explorer, although I can’t test that); but, as I mentioned in an update to the post, the highlighting doesn’t come through in the RSS feed (not a surprise) and the line numbering gets completely screwed up in Instapaper.

I’ve since learned that the line numbering gets lost if you use the Readability bookmarklet, which is unfortunate but isn’t as bad as the Instapaper mess.

Worse, though, is the rendering of line numbers in Mobile Safari. Here’s a zoomed-in example:

The line numbers and source code are in separate table cells, the contents of which are centered vertically. For some reason, the line numbers are given a smaller font size, which causes them to bunch up in the middle of the cell, unaligned with the corresponding lines of code.

I have no idea why this is happening, and because Mobile Safari doesn’t have the developer tools regular Safari has, I can’t inquire to see the styles that are being applied. When I look through the CSS, everything looks right, and the line numbers are being rendered properly in all the non-mobile browsers I’ve tested.

So, I apologize to those of you who read this on iOS devices (I’m assuming the same problem arises on an iPad). If anyone has an idea of what’s going on or has a suggestion for debugging steps I can take, please let me know. These niggling little problems can be very frustrating.


4 Responses to “Source code line numbers and the iPhone”

  1. Matthew McVickar says:

    I’m out and about and can’t verify this right now, but if I had to guess (and I have to!), I’d say that Mobile Safari is upping the font size of everything else for readability on a small screen but passing over the cell-contained text (maybe because it has an inline declaration or is being styled post-render. I’ll bet there’s a Mobile Safari-specific, -webkit-prefixed CSS property that would prevent this from happening.

  2. Matthew McVickar says:

    OK! I got home and saved this page as HTML in my local webroot, checked in Mobile Safari, and saw the same problem. Then I added this to the <head> in a <style> block:

    html
    {
      -webkit-text-size-adjust: none;
    }
    

    Mobile Safari tries to scale up fonts it thinks are too small for your screen, and -webkit-text-size-adjust (as seen in the Safari Reference Library) prevents that. I don’t know why it ignores the <pre> the contains the line numbers but not the <pre> that contains the code itself, though. I did some experimenting and found that it appears to depend on the length of the text per line in the containing block — no amount of lines containing a numeral or two triggers the scaling, but putting ‘Lorem ipsum dolor sit amet, consectetuer adipiscing elit’ on the first line does trigger it. I searched the WebKit source, but that’s way over my head; I couldn’t find the conditionals for the textSizeAdjust method.

  3. Dr. Drang says:

    Matthew, thanks for the hints. I hadn’t really considered that the iPhone is bumping up the font size of content area, but once you mentioned it, it’s obvious that it is.

    I found a page on quirksmode.org that mentions the problem of smaller table text on the iPhone, but it doesn’t talk about a solution. I’ll follow your links to see if I can come up with something.

    Also, given its larger screen size, the iPad may not have this same problem because it may not be bumping up the font size.

  4. Matthew McVickar says:

    I can verify that the iPad does not bump up your font size and thus displays the code in the table rows correctly.