I'm trying to understand why Windows Phone shrinks the font size when text is within a table cell and the table isn't 100%/nested.
The screen capture below is of a rendering test email I'm developing. In this case I sent the email template to a Windows Phone 8.1 device (SDK emulator image), and the problem I'm describing is clearly evident:
All the other tables that feature text are 100% width and the font size appears normally, but for the test results table that isn't 100% and uses table nesting, the font size has been shrunk to a very small factor. No matter I do I can't get it to be rendered at its intended size.
This only happens when using an EAS (Exchange ActiveSync) based mailbox i.e. Exchange because the rendering engine isn't the same as POP3/IMAP accounts.
Here's what I've tried that doesn't work:
Viewport meta tag
Adding a font tag with a size attribute
Use of -ms-text-size-adjust:none;
I've looked at several other similar posts on Stack Overflow about the problem and all the suggestions don't seem to work here. For reference here's the code I'm developing and what produces the behavior above.
https://raw.githubusercontent.com/jamesmacwhite/email-client-testing/master/email-rendering-test.html
Any advice?
After testing many different table layout techniques, I've come to the conclusion that its due to tables having pixel based widths. Using percentages, the email displays correctly.
More can be found here:
https://litmus.com/community/discussions/387-font-sizes-on-outlook-mobile-with-exchange-activesync-based-mailboxes
Related
I've just encountered a new issue that hasn't popped up in the 2.5 years I've been doing it. I send emails using Mailchimp and use HTML coding to format. Recently, my email campaigns have been clickable on desktop but spotty on mobile. Certain images will be clickable, certain ones won't - and when I return to the email, some new images are clickable or sometimes no images are clickable. It's very random. Below is an example of how I have always coded my emails. Picture of Code Used
You are using an area map to get precise locations on an image to link. However, on mobiles, those images are getting shrunk, depending on their size. Every email platform will shrink them differently, and depending on the content of the email, and the size of the images, they will shrink to different sizes.
So that explains the discrepancy you see. Now how to solve it?
Essentially, instead of providing one massive image, you need to use HTML + CSS, with tables and separate images and links. You need to lookup any modern resource on HTML emails and follow their guides or templates. This way, when the images move around to fit on mobiles, each image or word will have it's own link, and it will work consistently.
A project I'm currently working on needs responsive, lazy-loaded images with particularly flexible sizing: any given component may be rendered at the full width of the screen or down to 25% of it depending on other contextual elements, and we're trying to build for all screen sizes.
We're using lazysizes for our lazy-loading, partly because of its awesome data-sizes="auto" attribute that sets the <img> tag's sizes attribute to its exact pixel width before initiating lazy-loading.
The only real issue I'm running into is what to include as the srcset: we'd like them to be uniform across the site (so we can instruct the CMS to just auto-generate the same sizes for any uploaded image).
I'm tempted to say something like "here are the 5 most common sizes images will be rendered; include all of these and 2x all of these for high-resolution devices". However, this means including 10 sources for each file.
Are there any disadvantages to including lots of (more than 3-5) sources in a single <img>'s srcset?
The only ones I can think of (and that I've found searching for this elsewhere on the internet) are (1) server-side things (e.g. extra processing, more files to store) and (2) in the rare case where a user starts with a small window and resizes smoothly to a large window, the browser could download many copies of the same image. I'm not really worried about either of these cases.
I am developing struts2, Hibernate based web application, but its HTML, specially dynamic table, gets disturbed when it is accessed on different resolution systems.
I have already tried display tag, fixing headers of table and using percentage instead of pixels in CSS but still its happening, I want make a fixed design where all components should remain same on any resolution or it can auto adjust.
try using responsive tables these tables align according to devices and resolutions.
here is a plugin - LINK
or if you want to do it on your own look at media queries LINK
or take a look at the answer here LINK
Okay, so I am in the process of designing a website which has a login form at the top-right corner of a webpage. I set the size attribute of its input fields and I am getting some interesting results. Below is a group of screenshots that I threw together. I even stacked them for you all. I am even throwing in a jsFiddle for you all. So four things:
I aligned them based on the bottom right hand corner of the password input field in the stacked image. Don't ask why.
I design with borders on everything until the layout is correct, then I remove them and add the colors and images and whatnot.
The IE 9 screenshot is based on Adobe's BrowserLab since I am working on a Mac.
Note that the WebKit-based browsers (Safari and Chrome) render the same size.
I could not find anything to reveal what is happening after a series of searches. Maybe it's because it's hard to word a question like this into simple search terms (or at least for me)…
With all of this said, my question is why is are the input fields rendered so differently, and most importantly, how can I remedy this (without JavaScript or the dependence on User Agents preferably)?
The size attribute sets the number of characters that the field will display (in the case of text and password fields). Different browsers use different default fonts, font sizes, and ppi measures, meaning that you get massively different sized (in pixels) fields.
Also, as the spec says, this is merely the "initial" width of the control, and the browser is free to resize the control if it decides it needs to in the course of reflowing the entire page.
To even have a hope of making this field close to the same (pixel) size on different browsers, you'll have to style it with CSS. That being said, there is probably a good reason that each of these are different sizes - mostly having to do with default fonts - and if you pixel-restrict the size of the field that means some browsers will display more actual text than others.
We have a standard j2ee application written using jboss richfaces 3.3.x. we have several style classes to decide the size of the font family and size.
Some of the end users who use our application have their own font settings (in Mozilla under Tools-->Options-->Content-->Default Options-->Advanced. It has the checkbox "Allow pages to choose their own font, instead of my selections above".
Some have minimum font size set to None and some have it set at 18. In such cases the buttons get rendered bigger in size and it exceeds the button size resulting in a unusable UI.
Is this an issue with Firefox, we can't advice the customer to modify these settings. How are we supposed to handle these cases.
For sure, it is not an issue with Firefox. I would rather say it is an issue with your application. You don't have to force customers to modify their browser settings just to use your application. Instead, you have to adapt. Gladly every well-known browser let specify the accessibility settings you cannot override, like the colors, fonts or font sizes.
The magic rule every person working with UI must keep in mind is that if you force your customers to adapt to your app, they would go away and buy another application, which respects them and instead of imposing something, adapts to their needs, takes in account their disabilities and matches their habits.
Remember some customers may have difficulties reading small text. If they change their settings to set text larger or to set the minimum font size, it's often because they just cannot read tiny text on a high resolution screen.
Now, what can you do to ensure your application displays correctly? The most obvious solution is to test it, to see what happens, and to adapt the design. Increase the font size. Run your app. If text overlaps buttons, you may want to increase the size of the buttons.
It's always possible that they will have different font settings. Different size, different faces (with different height/width/kerning). Browsers have their defaults. OS's have their defaults (Win vs. Linux vs. Mac, even Win XP vs. Win 7). Users can override them with their defaults...
It can be an issue even with desktop apps.
The only way is to design the app in such a way that it looks nice and is fully usable regardless of font face and size. UI and widgets should scale relative to font size.