I have an odd issue, which only recently came to light.
Our database produces a list of sizes for products (e.g: Small, Medium, Large etc..)
There are also a number of sizes which are hyphenated (2-3YR, 4-5YR).
The sizes with hyphens show properly on most devices, but on IOS they look like this:
2-
3YR
4-
5YR
So IOS is breaking the line after the hyphen. I can't remove or change the hyphen as it's server generated, so is there any way to prevent this with CSS?
Thanks for the comments. display: inline-block didn't work for some reason. However I did find a JS workaround:
I used the following to substitute the hyphen after the page loads with a non-breaking hyphen, which seems a little akin to using a sledgehammer to kill a fly, but it works!
var str = elements[i].innerHTML;
var text = str.replace("-", "‑");
elements[i].innerHTML = text;
I recently ran into this issue and was experiencing it in ios chrome and macos safari.
Simply apply the following CSS to your element containing the breaking text:
word-break: keep-all;
set min-width: fit-content; to your text element ;) it worked for me.
Related
For some reason, the spaces between words on a font that I am using disappeared. See:
http://www.fantasynews.com/
I'm using Twitter Bootstrap slightly modified to use Google Web fonts. The font in question is Oswald served up by Google web fonts:
http://www.google.com/webfonts/specimen/Oswald
And the spacing appears normal for me there.
I'm no CSS guru, but I have touched nothing in my code that should alter the way spaces are displayed. I don't know of anything that should target spaces in particular. I feel like this is some dumb mistake that I'm overlooking but I'm clueless. If I view the source, the spaces are clearly there as well as the spaces clearly being there when I inspect the element, in case some bit of javascript was playing a trick.
I am using the latest version of Chrome, although this also appears in Firefox.
I should say that the spacing problem appears specifically for the title in the boxes under latest player news
I forced it by adding word-spacing: 0.25em to my CSS, but I'm not yet 100% sure that fixed it in every browser. It's unfortunate that Google doesn't have an obvious way to link to a particular version of a font so you could be confident it won't change from under you.
Removing font-weight: normal; fixes the spacing (there are 2 instances being applied to it, Inspect Element and you will see them)
EDIT: This is a bad font, you should choose another one! It looks fine bold, but the normal version is awful.
Same problem here, i applied another font to the online website and pray for a solution :(
It may be a wrong encoded file on google's servers. Nobody's safe from minor issue like these, even the guy who encode typos in the webfont service.
I usually use Firefox(newest) for Ubuntu 12.10. Everything looks fine there. In Chrome however, your fonts are most definitely squished. I personally would choose a different font that renders more consistently. If you want to learn more check out Mozilla's MDC Kerning page to get started.
The main way that I use kerning is with the letter-spacing property.
h2 {
letter-spacing: -0.1em;
}
To say that this addresses "kerning" would be false. This actually affects "tracking". The only difference between the two is that kerning is the relationship between two character and tracking relates to a block of text.
I have strange problems developing a site.
Any browser on my computer adds a spacing above some elements at the page (e.g. above the navbar, the dropdown in navbar, the container etc). In the Chrome Developer Tool it displays like having a strange text element (quotes with spacing):
but in source code it displays without it:
If I delete that quotes from the Tool, the spacing disappears.
That quotes (spacing) can't be added by Javascript or PHP: it exists ever it we comment all script includes and disable php preprocessing for .html files (example).
This spacing can't be added by CSS: e.g. for navbar we have rule:
.navbar {
margin-top: 0;
}
The spacing exists in all browsers at my computer (tested in Firefox, Chrome, IE 9).
Moreover, Firefox Dev Tool doesn't display any quotes:
but adds spacing in code in that places where are quotes in Chrome Dev Tool.
So, what's it? How to remove this spacing (I don't want to use ugly solutions like negative margin)?
Please comment do you have this problem on your machine? Thanks.
It seems to me, that the spaces are 'special spaces' like is one. They may look like a normal space character, even in a text editor
Look at the code, which generates the HTML structure.
Then delete the spaces in request. Put back the formating spaces by using the space bar key.
edit
looking closer in my text editor i realised, you have a special diacritical character in your code.
When you look a my screen from Notepad++ editor, there are small 'hooks' at the less than character (<) of the <nav> and the <li> tag which I marked red.
Don't just delete the spaces, delete the less than character (<) too and retype it using the keyboard.
The characters between the <body> and <nav> elements are a line feed and a BOM - Byte Order Mark (aka zero width non-breaking space) U+FEFF (EF BB BF in UTF-8). See the image below taken from Hex editor Neo
It's the BOM that you need to remove.
There is whitespace in your source HTML: between the <body> and <nav>. The only way to make it go away is by running the two tags together, as in
<body><nav class="..."> ... </nav></body>
HTML dictates that runs of whitespace outside of attribute values are treated as one single space, so it doesn't really matter how much whitespace there is, if it's newlines or not, etc. Even if you have a single space character in your HTML, a conformant browser has to treat it as a text node. It's these text nodes that Chrome hints to by showing the quotes.
Hey everyone, I'm working on a site and any special characters ("’" "…") turn into garbage at any font size over 19px. I'm using fonts I defined with #font-face, and the garbage disappears when I use a fallback font. This is Firefox 3.6.13.
I've tried defining the fonts in the page with a font: declaration rather than a font-family: declaration (see here) but it doesn't work.
I can use the standard straight quote and skip the special characters, but have you seen a straight quote in a heading at 40px? Ugh.
Anybody seen this bug, and any suggestions to fix it server-side?
Perhaps you will simply have to use another font?
After some more research, I (sort of) figured out what's going on. Firefox 3+ will automatically "optimizeLegibility" for any fonts over 20px (look up CSS "text-rendering" property).
For whatever reason, the fonts I am using don't render correctly when Firefox applies this value. If I specifically declare:
body { text-rendering: optimizeSpeed; }
Suddenly the problem disappears. Obviously this might bother someone who likes the effect of "optimizeLegibility" (it's definitely a nice effect), but if you can't change font-faces and you're getting garbage in your headings, I hope this helps.
Playing around with shjs in order to display line numbers, line breaks and spaces, i came across this: Using Pseudo-Elements for the ›hidden‹ characters it behaves just as expected (in Firefox): no line numbers, spaces or line endings get copied to clipboard.
As IE8 displays everything well, I was surprised it behaves different with copy+paste.
Copy+pasting a line from FF looks like so (which is fine):
config = ({
While the same, copied from IE8 reads:
14·config· =· ({¶
The same with Opera, btw.
Does anyone know which behaviour is the correct one, and if there is a way to teach the browser the desired behaviour?
Thanks in advance
Opera and IE are correct: There is no rule which forbids copying generated content. Mozilla’s behavior is btw one of the many reasons why you can’t use the <q> element …
Unfortunately, you can’t bring all browsers in line. Generated content is not part of the DOM and therefor not accessible per Javascript.
I am facing issues with text box size when veiwing in Fire Fox 3.6.
< input class="dat" type="text" name="rejection_reason" size="51" maxlength="70" onchange="on_change();">
style is as:
.dat {
font-family : verdana,arial,helvetica;
font-size : 8pt;
font-weight : bold;
text-align : left;
vertical-align : middle;
background-color : White;
}
Text box size in Fire Fox is bit smaller than IE6.
Not sure why IE6 and FireFox displaying text box of diff size.
Normal problem when developing for different web-browser engines.
Note that you maybe should develop for FireFox 3.6 rather than IE6 because IE6 have set to "old browser" that microsoft is not supporting anymore. Change your code to work good in FireFox, IE, Chrome, Opera.
look for more info at:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site
Try specifying the width in your css. If that remains broken, you can append an asterisk to the front of the width word as a second entry and it will apply only in IE6.
.dat
{
width: 100px;
*width: 105px; -- or whatever makes it look correct
}
EDIT: Thanks for the update on the special character.
With a more full explanation, which I just had to give to a manager;
IE6 was built around 2000, and ignored several significant web standards at the time. IE6 was somewhat of a "lesson learned"; IE7 is better about following those standards, and IE8 is better still.
Firefox was built around Netscape/Mozilla, and importantly, they followed the public standard as much as they could. Firefox largely behaves like Safari, Chrome, Opera, and the tons of tiny-marketshare browsers out there.
Businessperson asks:
So, why support the standard, instead of IE, which is the big kid on the block? Almost all of our customers use IE!
Answer:
Because IE is slowly moving towards the standard, too. If we support Firefox, IE8 is easy, and we probably get IE7 as well with almost no changes. IE6 is the fly in the ointment here.
If we support IE6 - the original proposal - then IE7 is a special case, IE8 is another special case, Firefox is a special case, and so on.
If we can encourage users to move away from IE6, that's our best case scenario. I believe Microsoft officially ended all support - including security patches - for IE6 when Server 2003 SP1 left support, April 2009. Google has stopped supporting IE6 entirely, for example, politely letting users know they need to upgrade "for the full site experience". Sites like IE6NoMore offer a pretty slick CSS popup for those running IE6, giving them a few upgrade options.
But in the meanwhile, since customers do use it, IE6 is here to stay, and it's easiest - and most maintainable - to build to the standards, and hack our way back to IE6 until it's done.
You have not specified its width just that you want it to take 51 charecters via the size attribute. I would suggest removing the Size="51" attribute and adding a style of width:666px;
EDIT: after your comment
Firstly just because you can does not mean you should. The corret way of solving this is changing all of your <input type="text"> to use a css class or css width to define their width.
However the following jQuery will add a width style to every input type=text which has a size attribute
jQuery( // on Document load
function($){ // run this function
$('input[type=text][size]') // find all input type=text with a size attr
.each( // for each element found
function(index, Element){ // run this function
var size = $(this).attr('size'); // get size attrubte value
$(this).width((size * 0.6)+"em"); // set the css width property to
}); // a nasty huristic
}
);
Now since this only effects inputs with size specified, as you touch each page you can remove the size attr and replace it with Css size, so eventuly you will not need this script.
The #size attribute gives a size in characters. However, unless you are using monospaced fonts, the size of a character itself is not something that is well-defined. In addition, different rendering engines may use different rules for character spacing and/or kerning. So, at the end, the attribute is no more than a vague hint to the browser.
Have you tried something like style = "width:51em;" instead? Haven't tested it, but the width property is well-supported, so I'd hope this would work. You can also use absolute (pixel) units if you want a more exact size.
Hope this helps.