Text in Split-Cell Tables Looks Smaller on Smartphones

[DXL]

When creating a page in Microsoft Frontpage (I know, I know), I typically have a main table broken into row and column cells. One particular cell is dedicated for that page's text.

In the content area cell, I often create a two-column table. Text will go in one cell, an image in the other cell. When viewing that page on a desktop PC, all text throughout the content area appears as the same size font.

But when that page is viewed by someone using Safari on an iPhone, Chrome or Firefox on an Android phone, not all page text displays the same. Most of the text in the layout table's main cell appears in a large font size. But the text will appear smaller if it's inside of a table I inserted within the main content area cell. If the new table I create is just one cell, the text will look fine. But if I split that table into two or more columns, any text in any of the cells will look smaller than the page's main text on most mobile browsers.

It won't matter if I go into the HTML and make sure all of that split-column table text has a specific font size tag (font size="4", etc). A friend tried to use CSS to fix the issue, but it still appeared the same.

So is there a particular reason why most mobile browsers display fonts in different sizes when they appear in a table split into two columns, if that table is inserted within a cell of an existing table?

[not2easy]

From Google's Page Speed Insights:

Web font size can be specified via four common units: pixels (px), points (pt), EMs (em), and percent (%).

Pixels are “CSS pixels” and vary based on device size and density.
Points are defined in relation to pixels. A single pixel is 0.75 points*.
EMs and percent are “relative” units: they are relative to the inherited size and properties of the font being used. 1 EM is equivalent to 100%.

Unfortunately, Microsoft Frontpage cannot create html that is mobile friendly. Mobile browsers can't understand the markup so you get "whatever" formatting, particularly the font sizes.

Mobile device friendly html does not specify width, it should be a liquid layout and there are too many other differences to go into, none of which would help you fix the code produced by FP. You can read more to get an idea of the basics at [googlewebmastercentral.blogspot.com...] and they offer all kinds of information, but you will need to learn or hire someone to get from where you are to where you want to go.

[lucy24]

What does your DTD say? If it's improperly worded, the browser may default to "quirks" mode, which includes making up its own rules about text size in tables. You can generally override it with an all-encompassing

table {font-size: 100%; font-family: inherit;}

A further problem is that some newer versions of Safari have gone completely haywire about font sizing. It's very hard to override this without forcing a font size-- exactly what a good site shouldn't do. But you may not have any choice if the browser itself has made it impossible for the user to set a preferred size. (This is really true. It's horrible.)

a specific font size tag (font size="4", etc)

Do not do this. Really. Change it. In this day and age there is absolutely no excuse whatsoever to use <font> tags. In the present context, "this day and age" means "anything coded after 1999".

Frankly it sounds as if your entire site is way overdue for an html overhaul. It is very, very difficult to make responsive design using tables. At a minimum, you'll need some @media rules that change table elements to {display: something-else} when the viewport drops below a certain size. Tables-for-layout, <font> tags and so on predate the very existence of mobile devices.

:: wanders off sobbing brokenly ::

[DXL]

Mobile device friendly html does not specify width

I wasn't aware of that. I'll check out the link.

What does your DTD say?

I had to Google DTD just to figure out what it means. I never bothered to learn how to use CSS. And the only thing related to page content in the coding is the "Content-Type" meta tag (content="text/html; charset=windows-1252").

Frankly it sounds as if your entire site is way overdue for an html overhaul.

I've developed countless websites for about 13 years now. Most rank well on Google, the more recent ones look okay on smartphones. But I agree that all of the HTML on any site I create is a throwback to 12 years ago.

I suppose I never lost any sleep over things like W3C validation errors, as long as a site was functional and ranked well. But for the sake of sites looking consistent regardless of mobile browser, I obviously need to rethink how these sites are coded in the first place.

[not2easy]

To be able to use default settings for mobile browsers, use charset UTF-8 rather than WIN-1252 because it slows those browsers down to convert the fonts. You can't just put it on the page, the html needs to be UTF-8 if you use that charset in your headers. Desktops gave a lot more leeway in what we could get by with. Lucy24 is right about tables and responsive design. You really would do yourself a favor to take time to learn css basics at least.

The header for html5 is so much easier than whatever you're doing now, save yourself headaches and don't keep building pages that will need to be fixed and are obsolete at birth.

[penders]

But when that page is viewed by someone using Safari on an iPhone, Chrome or Firefox on an Android phone, not all page text displays the same. Most of the text in the layout table's main cell appears in a large font size.

Text in wider blocks appears larger. AFAIK this is the same with all mobile browsers, regardless of whether you are using tables or your code is valid.

For example:

<!DOCTYPE html> 
<html> 
<head><title>Test</title></head> 
<body> 
<p style="width:30%;float:left;">Some text goes here, some text goes here, some text goes here, 
some text goes here, some text goes here, some text goes here, some text goes here, some text 
goes here, some text goes here, some text goes here, some text goes here, some text goes here, 
some text goes here, some text goes here, some text goes here, some text goes here, some text 
goes here, some text goes here.</p> 
<!-- The following text appears larger on mobile browsers (100%) --> 
<p>Some text goes here, some text goes here, some text goes here, 
some text goes here, some text goes here, some text goes here, some text goes here, some text 
goes here, some text goes here, some text goes here, some text goes here, some text goes here, 
some text goes here, some text goes here, some text goes here, some text goes here, some text 
goes here, some text goes here.</p> 
</body> 
</html>

[lucy24]

Text in wider blocks appears larger. AFAIK this is the same with all mobile browsers, regardless of whether you are using tables or your code is valid.

Do you mean, functionally, that if the same amount of text is allotted different amounts of space, each is resized to fit? Is it 100% and <100% or >100% and 100%, or do they split the difference?

Does it also work the other way around (different amounts of text in areas constrained to the same width)? Fortunately it doesn't seem to do this on the iPad-- I checked-- but possibly an iPhone would.*

Nasty, anyway.


* Although not on my site, because the main thing I use tables for is parallel translation, and those don't display as tables on small devices.

[not2easy]

No, it doesn't do that on the iPhone, but I only use it to check my own pages, it is not my first choice for browsing. I would think that only happens if there is inline or css styling that uses px for font-size. Though I notice the example has no viewport tag so that might play differently on different screens.

[penders]

AFAIK this is the same with "all" mobile browsers...

Sorry, "many" mobile browsers would be more accurate.

No, it doesn't do that on the iPhone, ...

It doesn't do that with "Dolphin" or "Next" browsers on Android either. However, it does with Chrome, Firefox, Opera and UC Browsers on Android.

I think the intention is to make "desktop" (ie. "non-mobile") optimised sites instantly readable on the small screen without having to pinch zoom. Double tapping the text block on these browsers expands that text block to full screen width.

Do you mean...

To be honest, I'm not sure exactly how it works! It seems that beyond a certain amount of text (about 250 chars playing with my example above!?), the browser enlarges the size of the font proportionally to the width of the container. I believe this is the text-inflating algorithm [developer.mozilla.org].

However, I think this can be avoided by setting the appropriate viewport tag (as not2easy suggests), playing with

text-size-adjust

(if absolutely necessary) and basically designing more responsively.