SuttaCentral on iOS

[sabbamitta]

A friend has a phone with the newest iOS version, and SC looks like this in Safari browser:

The borders are not readable.

I am not sure, is this for @HongDa? Bhante @sujato?

[Raftafarian]

It behaves far better in Chrome for iOS. Chrome is a free download from the Apple Store.

[sujato]

@sabbamitta

SC looks like this in Safari browser

@Raftafarian

It behaves far better in Chrome for iOS

Just so we’re clear: these are the same browser under the skin. Apple doesn’t permit any other rendering engines in the app store, so the only difference is in the UI, user settings, and the like.

Not to say using chrome isn’t better if that’s your experience. Software is weird! It’s just that the differences must be in settings and the like.

@sabbamitta

SC looks like this in Safari browser

Usually when it is overfull like that it is because there is an excessively long word. We struggled to solve this in Pali! Given that it’s German, it’s possible this is the problem here. This problem should be solved by hyphenation in the browser, but perhaps that is not working.

So I’d suggest open a short sutta and double check that this isn’t the problem. If not, we can go to the next step.

[sabbamitta]

@sujato

So I’d suggest open a short sutta and double check that this isn’t the problem. If not, we can go to the next step.

Thanks, Bhante. It’s well possible that there is a long word somewhere in a long Sutta like DN 16. I’ll tell him to check with a short one like Thig 1.1.

[sujato]

Thanks. Also the usual: refresh the browser.

[Pasanna]

I just tested on my ipad, which has the latest iOS, using split screen to simulate the smaller screen size which would be found on a phone.
In Thig1.1 there are no problems. Ditto DN15
I was able to reproduce the issue in DN16

It seems like the hyphenation is working. There are no long words in the body text which are breaking it.

[Pasanna]

I just plugged my ipad in and inspected in developer mode.
The problem looks likely to be occurring with how <main> is rendering.
All the boxes measure 320px up to that point and the <main> is blowing out to 462.25px
Then <article> and all the paragraphs inside are 426.09375px

[sujato]

Oh, excellent sleuthage. I can’t see anything that might be producing this, so we’ll have to dig a little deeper.

One clarification: does this occur in legacy text pages, or only in Bilara texts?

meanwhile, tagging @HongDa to test this on an iDevice.

If it works in DN 15, and there is no issue with the hyphenation, then I wonder if the problem is the size of the text: perhaps it is rendering the width before it is fully loaded.

To test this, try the first chapter of the Khandhakas in German (not segmented) or segmented English translation.

Which, while we’re at it, if the rendering time is really the issue, it would probably show up on the English page for DN 16 too?

[sabbamitta]

@sujato

if the rendering time is really the issue

I don’t actually think it is. I was present when this friend opened DN 16 yesterday, and it showed up within a millisecond (so it felt). I remember how amazing I found the speed of it.

[Pasanna]

I didn’t bring my iPad up from my kuti this morning. Depending how the day pans out I might be able to have a look this’arvo

[Pasanna]

I think I’ve found the offending paragraph

It’s at 5.25.30

5.24.10Zum zweiten Mal … 5.24.11und zum dritten Mal bat Subhadda Ānanda, und zum dritten Mal lehnte dieser ab. 5.24.125.24.135.24.145.24.155.24.165.24.175.24.185.24.19

I opened the page up and deleted each paragraph until things jumped back into alignment then undid that delete and things went wonky. I ran various other deletes to check my hunch.
The problem is all the segment ids. The max number it likes on one line seems to be 5.

Before:

After:

Out of curiosity I checked the English version and discovered at that same point it is messed up by the segment ids.

If I sent the .reference {‘float:left;} then all is good again, but the paragraph jumps out of alignment a bit. But with the paragraph p{overflow hidden;} then things look nice again.

This is my hacky solution. I’m sure there’s a nicer way to fix this

Please excuse all the edits on this reply. Typing on a touch screen

[sabbamitta]

Wow, amazing research! Thank you so much!

[sujato]

Excellent, thanks, I will sort this out.

It’s a bit tricky getting the CSS to work on all devices, with all the different layouts and so on. But modern CSS is super-powerful so we should be able to find something.

@Pasanna

.reference {‘float:left;}

Ha ha the 90s called, they want their float back.

@Pasanna

I’m sure there’s a nicer way to fix this

Indeed, let me see if I can test it now.

[sujato]

Okay so the issue here is this. The segments, and the things inside the segments, are set to display: inline. That means the browser just puts them one after the other in the line, like letters in a word. Unlike words, however, it has no intuitive way of knowing when it should wrap a line of elements.

So we tell the browser to wrap them with this code:

.reference {
overflow-wrap: anywhere;
}

Now, caniuse tells me that this should be supported on iOS on safari. But we can test this by using the deprecated alias word-wrap.

Can I ask you to test that, and assuming that this likely tells us nothing, next try this.

The structure (simplified) of a reference is:

<span class="segment" id="dn16:5.24.12">
     <span class="reference">
          <a class="sc refFocused" id="5.24.12" href="#5.24.12" title="SuttaCentral segment number">5.24.12
          </a>
     </span>
</span>

overflow-wrap: anywhere; is applied to the inner .reference class, which works fine on Chrome. Perhaps on Safari we need to apply it to the outer .segment class:

.segment {
overflow-wrap: anywhere;
}

Does that help?

[Pasanna]

@sujato

Ha ha the 90s called, they want their float back.

that’d make it retro and vintage code .

My iPad’s in my kuti. I’ll test either tonight or tomorrow.

[Pasanna]

@sujato

So we tell the browser to wrap them with this code:

.reference {
overflow-wrap: anywhere;
}

Now, caniuse tells me that this should be supported on iOS on safari. But we can test this by using the deprecated alias word-wrap

overflow-wrap doesn’t seem to want to play. So I went old-skool and changed

.reference{
display:inline-block;
}

from display:inline;

et voila!

looks the same in x-small windows on Chrome desktop and would probably work in Netscape Navigator

[sujato]

@Pasanna

.reference{
display:inline-block;
}

Okay, thanks. I have applied that locally. It’s a bit trickier than it seems, due to the various different views and their interactions. Also of course I can’t test it myself. But we’ll roll it out to our staging site in a few days, and I’ll see if you can test it there.

@Pasanna

would probably work in Netscape Navigator

Sadly no, inline-block has only partial support from the early 00s. I guess we’ll have to just abandon our Netscape Navigator users.

[sabbamitta]

Looks like translators are abbreviating too much, thus giving programmers a hard job …

Thanks for all the efforts erveryone! So hopefully on our next meeting we can happily read the Mahaparinibbanasutta with our discussion group.

[Pasanna]

@sujato

Also of course I can’t test it myself. But we’ll roll it out to our staging site in a few days, and I’ll see if you can test it there.

No problems. Let me know when and where