Google Chrome Text Size Remains Constant on the page - html

So I've come across an issue with a site today regarding strange behavior with Google Chrome. Essentially when the end user uses the built in "CTRL +/ CTRL -" functions to change the text size on the page, the images get bigger and all, but the text size remains constant. I've gone over the markup and css and can't find anything that would cause this. The site behaves as expected when the equivalent functions are used in Firefox and I.E. so I am wondering if anyone has any idea what would cause this?
Does anyone have any suggestions on what I should look for here?

Look for:
-webkit-text-size-adjust: none;
in your CSS.
If it exists, there's your problem. Change it to:
-webkit-text-size-adjust: auto;
or remove the reference altogether (it should default to auto).

Related

Safari in iOS 16 autofocusing form elements

I noticed that Safari in new iOS 16.0 autofocuses an input element if:
type=number or text
pattern=\d*
margin-top on containing element is 48px (I did not test the precise cut-off value here)
Test page: https://www.autoledky.sk/ios.php
autocomplete=off and autofocus=false doesn't change anything. Before iOS 16 there were no such issues. The problem is confirmed on 2 seperate iPhones with iOS 16.
This leads to automatic homepage scrolling, enlarging and opening the keypad, which is unacceptable.
How should I solve the issue without obvious "remove input/pattern".
I couldn't verify the need for any margin criteria. Our scenario didn't match the margins listed here. However I was able to fix our problem on an input[type="number"] field by removing the pattern attribute entirely since it is already a specific field time. By doing so we no longer are seeing the auto-focus in Safari on iOS16.0
I tried many things before finding this topic here and figuring out it was likely a bug, including changing tabindex, disabling javascript, working my way through every plugin on the site we used. Glad to have found someone else struggling with the same issues and having been able to narrow it down a bit more. Thanks!
Just adding my 2cts here, I had the same issue, and the problem was caused by an input element located outside of a form tag.
When wrapping the input within a form element, the issue disappeared; hope this can help someone else.

Chrome extension UI resizes / uses smaller values in production

This is a really weird bug that has already consumed half of my day.
I am creating a chrome extension and when developing the extension locally it looks fine (like I want it to look).
However, once I load the extension to chrome to test performance the UI looks a lot smaller.
I made sure both windows are at 100% size.
What is weird is that actual values change. Font that should be 16px in development becomes 12px in "production".
I have attached 2 screenshots:
DEVELOPMENT (How it is meant to look):
PRODUCTION (How Chrome renders it, once the extension is uploaded):
There you can clearly see the changes in font size and UI. Is this a known Chrome bug or something?
Any help or hint is appreciated since I feel kind of stuck!
Thanks!
maybe the answer of this thread could help you:
LINK
Seeing the images you attached, I can only assume that an ancestor tag (it could be the button or an even more ancestor element) uses a font size that conflicts with your "font-light" class declared 16px.
If by "testing locally" you mean opening the html page with chrome outside of a loaded unpackaged extension, then accept my advice to review your method.
The same html + css combo loaded in Firefox (almost certainly) would give an even different result.
It is also possible that the issue\solution lies somewhere else, but the concepts just outlined need to be taken into consideration.

Removing weird space between arabic words in Chrome

I'm working on a Quran web application, I've recently encountered a weird situation, please take a look at the following URL:
http://www.silverlight4web.com/quran/test4.aspx
this is just a sample page which looks fine in Firefox, but Chrome doesn't display it correctly, as you can see, there are some spaces between verses, I'm going to remove these extra spaces. These spaces are randomly distributed between verses, I've also applied word-spacing CSS tag which doesn't seem to be a remedy. What is going wrong here?
Also you can here view a screen shot of the error:
error screen shot
In this URL you can view another copy of this page, but this time with a regular font (Tahoma). It seems that the font is the main source of this problem. Is there any chance to overcome this problem while still maintaining the font?

Webkit (inside titanium desktop) shrinked fonts

This problem appears on every bit of text, no matter if it is table,div or something else
As you can see on every right side of text elements, 1-2 pixels is missing. Adding of padding never helps
Any suggestions please?
You could try to following fix for webkit browsers.
Replace the button span with your text class..
#media screen and (-webkit-min-device-pixel-ratio:0) { /* Safari and
Google Chrome only - fix margins */ your classname { margin-top: –1px;
} }
Have you set the viewport meta tag to specify its width and zoom scale? Maybe that would help? It's documented in the Apple dev docs
You could try using -webkit-font-size-adjust.
Look here for more info on it:
http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
This is happening probably because of
Inherited CSS property
If CSS does not seem to fixed it, check html doctype. Some tags although in rare cases do not work with certain doc types.
use !important attribute in CSS to enforce a certain rule be applied which discards all others.
try to set display: inline-block and a negative text-indent to <span> elements (embedded inside a webkit-only media query)
I have tried to deal with this problem for a month. Here what I have tried and found out. But I could not get actual solution;
I have followed up this thread, unfortunately nothing worked.
Tried several simple html documents with most possible doctypes,css,font-size,font-styles reset ..etc did not worked.
I discovered; when using with a remote url, it seems work fine, rendering is ok. When using embedded html pages, causing the problem.
In Titanium issue list; I have found out that, they represented as a Webkit bug.
https://jira.appcelerator.org/browse/TIDESK-136
Solution might be upgrading webkit version but Titanium has a lot functionality over webkit. So upgrading would not be an easy task.
My solution to this problem in TideSDK in windows was to do the following on the font in question:
font-weight: 600;
Maybe not the best solution for your application, (maybe you don't want to add any space or weight to the font since it seems you may have a much larger table of data to display) , but acceptable by my client.

Why is textarea draggable in Firefox 5?

See this link - why are the multiline textboxes draggable?
Is this Firefox bug? It just spoils the design like anything.
Even the same in happening is Stackoverflow's textbox. I am using Firefox 5.0
Thanks in advance:)
Edit:
See these photos of SO itself:
This is a feature that's been included since Firefox 4. However, you can switch it off by including resize: none in the css of the given Textarea(s).
That's something happening since some time now even on Chrome and maybe other browsers too. I think it's to allow a better experience for the users who need to type text in the textarea, so I definitely think it's not a bug.
But it indeed can mess up your website layout. You have to use some CSS to fix it, like
#yourtextarea {
width: /* fixed width here */
height: /* fixed height here */
}
In case the above doesn't work, you may also think about use min-width, max-width, and the height equivalents.
I won't mess up with this anyway, since it's a browser feature and so it's something useful for the users.
Why are the multiline textboxes draggable?
They aren't. Dragging just selects the text inside them. They can be resized though, which is great as it lets users make textboxes bigger so they can see more of their text if they have typed a lot.
Is this Firefox bug?
No, it is a feature. I think Chrome got it first.