When using the musical flat sign (♭) on a mobile browser, it renders an extra space before it and it seems to mess up the line height too. I've tried
Different fonts (still happens with no specified font)
font-kerning: (none|normal|auto);
The letter-spacing property, which fixes it on the phone, but breaks it on the desktop.
Is there anything I can do to fix this bar using images?
Here are some screenshots.
Chrome desktop:
Chrome mobile (Notice the boxes aren't all the same size and there is a space before the ♭):
This reason of this kind of occurrence to happen lies on the line-height property.
You can inspect this behavior with google inspect tool (Ctrl+Shift+i) with google chrome.
you can easily see that those "higher" cells are getting the extra height from the font itself (not from the padding,margin or anything else).
Just add:
line-height: 1;
It will cause the font height to be fixed.
*note : use letter-spacing property inside media query to target only mobile screen.
Related
I am having alot of trouble putting my problem into words, and it would be much appreciated if someone could perhaps 'sum it up better'. Anyways, I'm styling a form to gather information, as it is targeted at a mobile device, I want the fields to stretch to 100%, filling the screen. Using a text area, this works fine on all mobile OS's, however, by using a standard , the layout on the iPhone is broken, note this does not occur on Android. I believed it was a bug with Safari, but it works in desktop Safari, so maybe something to do with iOS rendering?
Standard expected behaviour.
iOS behaviour
Note:
A live preview of the site can be found at http://www.draganmarjanovic.com
However, this is only present on a resolution of <720px.
The same CSS code is used for both the input and the text area. - Cheers
The padding on the textarea and the input are different by default (user-agent stylesheet) and you haven't given a reset value for them. Try setting padding:0; on both of them, it should work.
Why did it work when you tried box-sizing:border-box; as #MLeFevre told you, you ask? Because what this property does is make the padding count as width and not as an addition of it (which is the normal browser behaviour we've had till CSS3). It does the same with border width too. So, it didn't matter the default padding wasn't zero because the width would be 100% no matter what padding you set.
I'm designing a website and using jquery UI majorly for the icons/icon-classes it provides.
While testing in chrome what I see the default height of a span element which wraps some text without padding or border gets a height of 20 px.
I understand it will differ with the type of font and size, the defaults and the browser. Is there anyway I can set height of a text to a given size?
If I understand correctly, it seems your facing this problem because of the way different browsers render fonts.
If you font sizes are influencing their parent elements size, then you may need to rethink how you are using margins and padding's.
EDIT
You could use line-height to try and tame the behavior.
When using same font, chrome and firefox give them different line heights, and sometimes you need them to be the same across browsers... Right now when encountering this issue, i have to give both font size and line height in pixels, but it doesn't seem like the best solution. Should different units be used may be? How do i make chrome and firefox render fonts similarly?
You can set line height as a pure number, which will by definition be taken as relative to the element’s font size, e.g. line-height: 1.2.
You can alternatively use the em unit, e.g. line-height: 1.2em, but then inner elements would inherit (unless they have their own line height set) the computed value, not the relative number. This matters if nested elements have different font sizes, and usually it’s the relative line height that should be used.
Please use a CSS reset from Yahoo, that should resolve cross browser issues.
First off, this is not the zoom issue that I've seen in other questions. Also, I'm testing this using an iPhone 4, running iOS 6. In working on a mobile project, I discovered an issue with the viewport tag and mobile safari. I distilled everything into code as basic as I could get it. I have there parameters set:
width=device-width
height=device-height
initial-scale=1.0
maximum-scale=1.0
user-scalable=no
It all works fine, until you rotate the screen. Nothing gets resized, and a black bar appears on the right side to fill in the gap (see screenshots). If I remove height=device-height completely, the problem goes away. However, I do need to use this parameter. Otherwise, I will have to ask a different question.
After rotating back to portrait mode, that black bar remains, and I can scroll left and right. This is a very strange issue. Removing width=device-width does something else unexpected. I have the code here if you would like to try it: http://toastd.net/viewport.html
Here are some screenshots:
Here it is working fine in portrait mode:
When rotated to landscape mode
Then rotated back into portrait mode
The meta tag will help define rules for the viewport but you still need to apply visual styling to address the change in orientation. Give these CSS values a try:
body { width: 100%; height: 100%; }
If you'd like a good resource to help continue your project, PhoneGap has a starter app on GitHub that you can fork.
PhoneGap Start
I believe this is a bug on Safari, but I figured out a way to work around it. It has to do with certain elements and their styles. By process of elimination, I narrowed it down to a few "offending" HTML elements. Deleting width: 100%; from some elements and CSS styles, as well as other static widths like width: 120px; would start to get reduce problem. I say "start to reduce", because the margin on the right became smaller, but didn't go away completely. I then started playing with other CSS attributes like margin and padding. After getting rid of some left and right padding from some elements, the problem finally went away. But this wasn't really acceptable, as those styles were there for a reason.
The solution was to wrap everything in a container element, size that appropriately, and set overflow: hidden; in CSS. Setting overflow: hidden; to the body or html tags would work too, but that did funky things with vertical scrolling in Mobile Safari. In my case, there was already such a container element, so all I had to do was add the overflow property to it.
Like I said, I think this is a bug in Safari. When you rotate from Landscape to Portrait, everything should be resized back to fit portrait mode. Visually, everything does look like it was resized properly. However, Safari must have thought something wasn't resized properly, so it displayed the page wider than it really was. This works just fine in Chrome on an Android device. I also added different background colors and borders to highlight which element might be causing the page to stretch beyond the width of the device screen. Visually, there was no apparent culprit.
If you're thinking it might be a width: 100% plus padding issue, I had the same thought. But then deleting either the width or the margin/padding alone should have fixed the issue, which it did not. Not a single element was sitting beyond the edge of the screen. There was nothing but empty space there.
It works in IE and Safari but breaks in Chrome. You can view the page here http://www.archemarks.com.
It only breaks at a middle zoom point so you have to zoom in and zoom out and at this middle point the table breaks.
This made me think it was something minor that as the browser re-drew the page..the changing pixels available caused it to make something bigger than normal...or smaller and broke the layout.
Chrome has development tools which should make all of the CSS and HTML available.
I tried fiddling witht the size of the text in put box and the containing column and row..but this did not help as I was only guessing.
Any non-guessing advice.
I can repost the code but it might be easier to just view the site using Chrome Development Tools
It's the width of your .t2_c1 rule. At only 100px, it isn't wide enough for the Email Again text. this is undoubtedly because of the font size conversion being just slightly off as the browser compensates for the zoom. Changing the .t2_c1 rule width to 110px and then the .t2_c2 width to 250px fixes this issue.