I've setup a demo as follows:
<div>Bar Foo</div>
And styles:
div {
width: 100px;
overflow: hidden;
border: 1px solid black;
white-space: nowrap;
text-overflow: ellipsis;
font-size: 50px;
font-family: 'Pacifico', cursive;
}
Now, In Chrome the dots of the ellipsis are in the correct font, but in Safari the dots are in a different font. Is there a way to fix this ?
The central issue is that the Pacifico font as used in the demo* does not include an ellipsis character (U+2026). Safari uses that character when text-overflow: ellipsis is active. Because the character is not present in the active font, the font-fallback mechanism selects a different font that does contain the character and that is what is rendered.
This does not occur under Chrome because Chrome apparently synthesizes an ellipsis using the glyph shape of the period (U+002E) character (it's not clear to me whether Chrome always does this, or only in cases where the font doesn't include U+2026).
*Note: the complete Pacifico font on Google fonts does appear to contain U+2026, so it's something to do with the font getting subsetted when using webfont.js as in this demo.
Related
I have this code:
<p style="line-height: 1;overflow: hidden;">blah_blah</p>
<p>blah_blah</p>
<p style="line-height: 1;overflow: hidden;">qypj;,</p>
<p>qypj;,</p>
which results in (notice no underscore, and cut characters):
That is, it behaves that way in Firefox (66.0.3 on Windows 10). Other browsers seem to render the underscore. The above snippet runner also seems to work (even in Firefox), unless you run it in "Full page".
This Q is similar to Text changes height after adding unicode character except there are no tricks here. "_" is just a simple ASCII character.
My question is which behavior is the correct one.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)? Shouldn't line-height: 1 imply it can fit exactly any text?
I suppose some characters are special, such as "p", "g", "j" (and possibly "_") that draw below its line. Still which behavior is the correct one. Is it considered overflow or not?
PS: Furthermore I find it funny either overflow-x: hidden;overflow-y: visible; and overflow-x: visible;overflow-y: hidden; still causes this. Which seems more like an actual bug to me.
My question is which behavior is the correct one.
All of them are correct because we don't have the same default font in all browsers and it's also different depending on the OS.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)?
Character doesn't change line-height. To be more accurate, line-height is a property that can only be changed by setting line-height but you are probably confusing with the line box that is defined by the line-height and a character alone cannot change it.
Shouldn't line-height: 1 imply it can fit exactly any text?
Not necessarely, line-height:1 means that the line box will be equal to the 1xfont-size 1 but is the font designed to include all the character inside this space? Probably most of them will do but we don't know.
Basically, you have two things to consider. The content area that is defined by the font properties and the line box that is defined by the line-height. We have no control over the first one and we can only control the second one.
Here is a basic example to illustrate:
span {
background:red;
color:#fff;
font-size:20px;
font-family:monospace;
}
body {
margin:10px 0;
border-top:1px solid;
border-bottom:1px solid;
animation:change 2s linear infinite alternate;
}
#keyframes change {
from {
line-height:0.2
}
to {
line-height:2
}
}
<span >
blah_blah
</span>
The red is our content area and its height is defined by the font properties and if you inspect the element you will see it has a height equal to 23px (not 20px like the font-size) and the borders define our line box that we control using the line-height.
So if the line-height is equal to 1 we will have a line box equal to 20px which is not enough to contain the 23px of the content area thus it will get truncated and we may probably hide some characters (or a part of them) which is logical:
span {
background: red;
color: #fff;
font-size: 20px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
a different font-size will remove the underscore in Firefox:
span {
background: red;
color: #fff;
font-size: 26px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
Another example with a Google Font where the result should be the same cross browser. The underscore is visible but not the ^/¨
span {
background: red;
color: #fff;
font-size: 26px;
font-family: 'Gugi', cursive;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=Gugi" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
Another example where the underscore is not visible:
span {
background: red;
color: #fff;
font-size: 27px;
font-family: 'PT Sans', sans-serif;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=PT+Sans" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
You can clearly see that we have a different overflow everytime we use a different font which confirms that this is font related. We have no control over it unless we know how the font is designed.
Related questions:
Understanding CSS2.1 specification regarding height on inline-level boxes
Why is there space between line boxes, not due to half leading?
Line height issue with inline-block elements
Here is a good article to get more accurate details and calculation: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
A quote from this article:
It becomes obvious that setting line-height: 1 is a bad practice. I remind you that unitless values are font-size relative, not content-area relative, and dealing with a virtual-area smaller than the content-area is the origin of many of our problems.
1 : I considered a simplified explanation but in reality the calculation of the line box is not only relate to the line-height property.
The default line-height (depending on the font-family) when not otherwise specified is about 1.2 in most browsers. This includes Firefox.
This would explain why the underscore did not show in FireFox when the line-height was set to 1 - the bottom was of the line was cut off. So I don't think it's entirely to do with the font (although this does contribute), but also browser defaults.
Some font-sizes are bigger than other even at seemingly the "same" font size (as I'm sure you've seen when typing documents in e.g. Georgia vs Times new Roman/Baskerville ; so you wouldn't be guaranteed that text would always show on a specified line height of 1 (or 1.2). There are ways of measuring a font in pixels however
Hope this helps
If I use the browser tools in Firefox to inspect my snippet below, there is no height difference between the lines with and without underscore. The only difference is caused by the line-height setting: 16px with line-height: 1, 19.2 px with the browser's default line-height. So the underscore doesn't make a difference here (Firefox 66.0.3 on Mac), and it is visible in both cases.
Note that I set margins to 0 to see the "pure" line-height without distances between the lines. Also, I didn't specify a font-familiy setting, so the default font of the browser for p tags is used.
The only reason for what you describe which I can think of is a font with very particular dimensions/settings, where the descenders (i.e. the parts of letters like p q j which extend below the baseline) are not inside the line-height as defined by the font.
After a bunch of comments back and forth: I suppose it could be caused by the different default (system) fonts on Windows and Mac. Still a bug, I would say (if you are using the default font).
html,
body {
margin: 0;
padding: 0;
}
p {
background: #fb6;
margin: 0px;
}
<p style="line-height: 1;overflow: hidden;">blah_plah</p>
<p style="line-height: 1;overflow: hidden;">blah plah</p>
<p>blah_plah</p>
<p>blah plah</p>
I am looking for a way to underline heading that has more than one line, gradient background [EDIT - background image that is not solid color, but gradient], ignore descenders (so border-bottom is not a solution) and that it will look good in Chrome (simple text-decoration: underline is very thick in Chrome).
I have checked all solutions mentioned here: https://css-tricks.com/styling-underlines-web/ but nothing there solving my problem (exept "avoid using an underline altogether" :)).
And as far as I now, Chrom still doesn't support text-decoration-thickness
The requirement to ignore descenders means that one is more-or-less forced to use CSS text decoration because who else knows where there are descenders? The alternative might be to have span around every character with different formatting, not really practical.
It transpires that Chrome will support text-decoration-thickness but only with certain conditions. From https://caniuse.com/?search=text-decoration-thickness:
The text-decoration-thickness property does not work unless either
text-underline-offset is set to something other than auto or
text-decoration-color is set to something other than currentColor. See
Chromium bug 1154537
It is therefore possible to control the underline thickness. It is more problematic trying to get the Chrome and Firefox implementations look exactly the same from the point of view of offset (FF seems to place underline by default further down than Chrome) and the two browsers do not treat descenders exactly the same way. Hopefully setting the thickness and tweaking the offset will result in an acceptable heading.
Here's an example
div {
font-family: Arial, Helvetica, sans-serif;
font-weight; 400;
font-size: 3em;
width: 300px;
text-align: center;
text-decoration: underline;
text-decoration-thickness: 2px;
text-decoration-color: black;
text-underline-offset: 0.1em;
}
<div>To jest kryzys ekologiczny i klimatyczny</div>
This page was auto-generated by Emacs' org-mode HTML export. I've got it set up to use MathJax rendering of LaTeX symbols. On the third column of the There Exists line I've used inline LaTeX symbols surrounded by "$"
$\exists x \mid x2>x$
which is proper LaTeX embedding, whereas the line above and below I haven't, i.e., Emacs just picks up LaTeX markup and inserts it without using "$". If you Inspect (I'm using Chrome) this code, you'll see it is throwing in a font-size increase for only this LaTeX markup, seemingly arbitrarily, making the symbols look abnormally large compared to the other symbols.
<span style="display: inline-block; position: relative; width: 5.681em; height: 0px; font-size: 129%;">
How can I stop, block, override this element.style being inserted and blowing up my font size?
element.style {
 display: inline-block;
 position: relative;
 width: 5.713em;
 height: 0px;
 font-size: 129%;
}
Update:
I've narrowed the problem down to something in my custom stylesheet.css:
table {
/* font-family: monospace; */
font-family:'eulermedium_18';
/* font-size: 1.05em; */
margin-left:5%;
margin-right:auto;
margin-top:0.5em;
margin-bottom:0.5em;
line-height: 1.5em;
}
namely, the font-family. Above I've commented out monospace, which gave me a 129% arbitrary size. But then as you see I tried AMS Euler (ttf version converted by Font Squirrel, as is the Computer Modern) and it caused the $...$ parts of the org-mode table in question to reduce the font size to 53%! Craziness. Again, with no font-family in table sizes are normal across LaTeX/MathJax and regular text. Is there any way to have the org-mode HTML export for MathJax stuff use my fonts correctly?
It seems to be related to font-family too. Column 3 of There Exists line seem to be use font as STIXGeneral-Italic, while the default font used at other places seem to be monospace. You can override these styles in your stylesheet.css using !important directive.
.mrow span{
font-family: inherit!important;
font-size: 100%;
}
http://www.alecos.it/new/125027/125027.php this link is an example of my problem... I used a png 1x16 for drawing the rows... the rows are visible in the link posted... my question is:
why under IE 6/8, FireFox, Opera, Safari and other browsers the rows are perfectly aligned with the text while under IE 9/10/11 the text do not fit in the rows?
I used a simple css:
/* Style Source Code */
.code {
border-radius: 7px;
border: #6666FF 1px solid;
background-color: #FFF5EE;
background-image: url("../bkg/Bkg_116.png"); /* Horizontal Rows */
background-repeat: repeat;
background-position: 0 10px;
}
/* Style Source Code */
.xcode {
color: #008000;
font-family: 'Courier New', Courier, FreeMono, 'Nimbus Mono L', monospace;
font-size: 13px;
font-style: normal;
line-height: normal;
font-weight: normal;
font-variant: normal;
}
/* Style Div */
.alignment {
line-height: 20px;
text-align: justify;
}
Hope in workround to fix the issue...
here there is my css: http://www.alecos.it/css/alecos.css
I'm not on Windows machine right now but my guess is .xcode(line-height:16px;} would solve your problem, but I must say that this is the wrong way of creating row borders. Why not add:
.xcode td{border-bottom:1px solid #ddd;}
instead of using background image?
Firefox is temporarily outdated unti it's next update meaning that it's browser does not have the ability to process codes in the same manner as other browsers.
.alignment {line-height: 20px;}
Gets over ruled by .xcode line-height normal;
IE aint normal ;)
Besides content tages like h1, p, font all have slightly different margins/paddings around them. So a non responsive img isnt the best way to go.
Would be better if you could wrap each line with a span, div or sinces its a table a tr,td and give those a border-bottom.
Gr.
Kevin
In order to make your text inside .xcode aligned with the horizontal lines, the "code" lines must be distributed vertically. Unfortunately, It seems that you did not understand the meaning of line-height property and use the default value without considerations.
The line-height property
As you can see, the line-height property will decide how much is the distance of two lines of text. In your case, we need it to be exactly 16px inside the whole block of .xcode.
The value of normal value of the line-height property
From the W3C CSS spec, the value of normal value is defined as:
Tells user agents to set the used value to a "reasonable" value based
on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
From some online resource like this article or this page, you can see that the real value of normal value depends on many arguments like font size, font family, OS, user agent, ... Therefore, it is recommended that you should use some css normalize stylesheet to set the value of line-height correctly and cross-browser.
About your case
The quick fix here is setting the line-height inside the .xcode class to be 16px (which is the height of the of your background image).
im trying to ellipsis a h2 tag with text-overflow. It works fine i all browsers but on Android.
The three dots jumps behind the clipped text so you can't actually see the ellipsis.
The css for the h2 is:
h2 {
font-size: 20px;
display: block;
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis;
width: 40%;
}
I have a lot of other styles but can't figure out what will affect this.
I did a dummy test which works fine, so i was wondering if someone experienced this behaviour before?
So i managed to figure it out, by running through the css line by line. It turns out that text-rendering: optimizeLegibility;
causes the bug!
Removed it and now it works perfectly!
this worked for me
Basically add text-rendering: auto; to your css that has the ellipsis
https://github.com/driftyco/ionic/issues/663