Context:
The idea is to add a graphical annotation, beside (or above) specific lines of text within a html text area. This is done, by overlapping a "auto generated" div item, above the textarea.
However while the alignment is perfect on most browsers, the custom font used, does not translate over to safari. And hence, it becomes misaligned, after falling back on it.
So the question is:
Whats the font use in the mobile safari text area (to calculate the spacing from the left) and how to derive its position, at any point of the text in a line? (even if it is not an even letter spacing font).
Related
Edit: I had been using a custom font "Gotham" (downloaded folder of fonts in my project) in the #font-face which appears to be the source all of the bugs. Not really sure how to fix it though. Is there a way to fix these issues while keeping my custom font?
Edit #2: the issue has been fixed with ascent-override: 80%; in the font-face. But this doesn't work on Safari browsers. Is there any solution?
When I resize my browser's window height while testing my website, there is a horizontal invisible line cutting off my h1/h2 text. From my research, it seems to be something due to line-height, but im not sure.
Thoughts I had:
When I don't set a line-height for the h1/h2, their height renders to 0px and are just invisible. The p tag in the middle seems to be fine with/without line height, I don't understand why?
see below, all line height removed
When it does have a line height, the text of the h1/h2 seems to be offset of the container. When I highlight the h1 in devtools, the text is higher than the box, outside of the margins.
When I resize my window, the 'invisible line' cutting into my text seems to be in the same spot, while my text moves up and down with the page resizing. So when the invisible line is between lines of the h2/h1, the page looks normal.
I have a script animating numbers that sets the innerHTML to the next number. Maybe the use of .innerHTML is screwing something up? When the animation happens, the invisible line cuts into the numbers like so. But for some reason it fixes itself when I resize the window.
Maybe it's the font I'm using? I'm using a custom font 'Gotham' and have it set up in the #font-face in the css.
Sorry for the bad description, but I did my best. Let me know if I could clarify anything. Could someone point me in the right direction?
I can't add a comment so adding an answer, can you not use box-sizing to resolve this?
https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing
This should then force the h1/h2 to remain within the box rather than cutting part of it.
I have a s-d issue with Jodit (which I much like!). The two leftmost standard toolbar buttons "grow" with a large screen, and thus cause the toolbar to occupy the whole space above the text area (align=even, kind of). .
The text area is in div which is again wrapped within another div with "d-flex". Perhaps someone has come across this?
In Firefox, the exact character width is adjusted (to nearest pixel) for on-screen viewing, but such adjustment does not occur in the print view. This means the number of lines in a paragraph (after wrapping) would differ.
I have some JavaScript that is used to add vertical margins to make two columns line up correctly, within a fixed width div. The alignment is correct on the screen, but not in the printed document.
I could make the font size and images very large and then use CSS transform: scale(0.1) to make the results small again.
I could have JavaScript separate each line in its own div (after wrapping), which would let me use white-space: nowrap.
Can you suggest something easier with less side-effects? Perhaps a CSS rule I'm not aware of?
I did notice if the user uses Ctrl+ zoom feature, then the problem goes away to some extent.
How to determine on which row of textarea is the cursor with javascript?
I think it will involve fiddly calculations with font sizes, padding, borders, margins, and line breaks. I expect it'll be hard to get it right in the general case. You could take a look at the source code of the following, which displays an autocomplete dialog as you type in a textarea. It was posted on Ajaxian recently and does what you need to do: http://media.chikuyonok.ru/content-assist/
I'm in the midst writing a Lessig-Method slideware object in javascript (so something fun, not important), and I keep encountering strange text layout anomalies, the likes of which I can't say I've ever seen. And yet, they are pervasive across my slides.
The background is straight-forward. Presentation has Slides, and Slides have Lines. A line, could be a word or a phrase, and in the images I'm linking, the slides have three Lines.
The presentation "screen" is the viewport of the browser window. The CSS line-height property of each Line is calculated by the viewport height divided by the number of lines. Each Line is a div with a font-size comfortably below the line-height (90%, but set in px).
A good looking slide looks like the first one on this page:
bbby.org/share/so_pics.html
(I can add only one link).
Here's where it gets weird:
Because everything calculates based on the viewport size, having the firebug console up, or switching to full-screen mode adjusts everything's size (upon refresh). In some cases, the first one to three letters of a word pushes all the way to the left of the screen, stacking on top of each other. The only thing different is that I went fullscreen and refreshed (and new sizes were calc'd).
Depending on the font-size modifier I set (90%, 80%, but again set in px), it could happen on a regular view (not full screen).
Has anyone ever seen anything like this before?
Funny that there are badges for trolling. I'd hate to see this site become the new youtube or failblog in our comments are issued.
That aside, the effect is controllable (though still not explained). By fine tuning the fontSize via script, I can see at what point certain letters in words fall apart.
For example, in a div with lineHeight=269 , the letters "ri" from the word "right" fly away as pictured in the original post with a fontSize >= 209 , but nothing under. The letter "l" in the word "left" has a higher number, possibly increased because "f" is also a tall letter.
For a currently consistent workaround to this very real and troubling problem (tyvm), I'm setting the fontSize attribute to be 73% of the lineHeight on the parent container.