I'm trying to make a long web page with text and images. I have a huge slab of text followed by an image - not ideal, blame the client!
This can look perfect on Chrome - matching the view in hype, but on Safari there's a gap between the text and the image.
I guess this is because the browsers are rendering the text differently. I have also tried scaling the page inside a group and the problem can be either a gap or text over-running the image.
I guess that while hype is great in most situations, this is one where the differences in browser rendition kill it's ability to do well cross-platform/browser.
There are definitely minute differences in text rendering between Safari and Chrome which can add up over the course of large text. The approach I often take to investigate first is to screenshot both and then compare on top of each other (with 50% opacity on the top image) to see if anything stands out. Sometimes stuff like the line height value is all that is different.
I'd be happy to take a look if you want to attach a zip of the .hype document. There's a low but non-zero possibility it is something that might be solvable.
In the original document, the text lines up identically in Safari and Chrome for me.
My best guess would be that you have a zoom factor set on the webpage. Try hitting Command-0 in Safari and Chrome to make sure you're at 100%. Safari's redoes its text metrics at different zoom factors unfortunately and there's no saving it.
Does that help? If not there might be some other configuration difference, or perhaps you're using a much older version of one of the browsers?
However iOS vs. Desktop Safari definitely uses a different line height value. Using a fixed one like @h_classen recommends is the way to go. We have plans to try to have Hype fix this in a future release.
I don't think it's as simple as line height, and there was no zoom factor on the webpage involved. I can see that the text flow differs between safari and chrome, so that's the biggest factor in changing the height of the text column.
My real problem is that I need a stacking relationship between these elements and because of the way Hype works it doesn't exist. I have established a stacking relationship using a bit of javascript, so that's OK - my problem is solved.
Thanks for getting back to me.
[ As an ex-flash developer, these problems didn't exist with flash because the rendering engine didn't differ between platforms - not blaming Tumult it's just the way things are. One thing I really hate about hype is that groups in hype have bounds that can be very different to the bounds of the content of the group - that's been a real pain on this project - much preferred Flash where the group bounding box was always determined by the content. ]
Hype works with absolute positioning. Hence, you can't expect reflows, as each rectangle isn't aware of the other. I ran through your example and font size became pretty stable with fixed line heights and a font selection that is guaranteed to be similar across devices. System fonts usual are not. Hype offers a flexible layout system for alignments and proportional positioning and sizing. But again, the rectangles don't really influence each other when using it. You can always break out of absolute positioning by managing a subtree of elements yourself in a rectangle (div container).
For other scenarios, Hype might not be your ideal solution or if you want or need to make it work look at observer-based solutions like resize observer. Also, this might be interesting for you:
I had no expectation of reflows. This is just an edge-case and I naively thought that browser behaviour would be consistent and it is not. If there was consistency across browsers I wouldn't have an issue.
I am not criticising Hype in any way. I have a work-around so that's fine.
Hype is being used because this is a small project. Unfortunately like a lot of small projects it's turned out to be not so simple as I thought it would be.
Don't worry, I didn't take it as such. Ultimately part of Hype's purpose is to iron out many of the browser compatibility wrinkles like this for users .
Unfortunately I can't observe this on your document though; they are basically pixel-accurate to me when I try on Monterey 12.2 (beta) with Safari 15.3 vs. Chrome 97. I'd love to be able to figure out how our configuration differs and see if this is something Hype can account for.
Can you let me know what versions of the browsers and macOS you're running? Could you also perhaps make private browser windows on both and take screenshots of the entire document window (not scrolled) for both and send those along?
I'm using Monterey 12.1. , Safari 15.2, Chrome 97, firefox 95.02 on a 2018 Macbook Pro
I have to say that h_classen was very helpful when he mentioned using a fixed line-height. I can now position elements reliably provided that the line height is fixed. If the line height is 'normal' my javascript doesn't work ( probably because of text overflow ).
I may be mistaken about text re-flow (probably my settings). I have attached an image.
Yes, because if your font is not reliable, it will become longer and surpass its bounding box. Meaning, it would be hidden if you set overflow to hidden. You can dynamically adjust the bounding box in Hype as seen here:
But, making sure that the layouts is reliable would be a worthier goal to me and should be achieved with @h_classen suggestion: fixed line height and font (meaning setting a non system font).
Absolutely right. I just pasted text into hype and didn't set the font. I have repeated my test with a specific font and set a specific line height - everything is now cohesive.
It's been an interesting journey - one I wouldn't care to repeat!
I also wonder if Hype's bizarre behaviour (text box boundary moving position mainly) when editing long columns of text is also down to using a system font...
In the screenshot you posted the leftmost image appears to be Firefox and not Safari. FWIW Firefox and Chrome do render differently even for me here.
But now looking at the inner html code and your first set of screenshots, I can see that the primary problem is that you are using local font names. I'm guessing you have the fonts actually installed. Safari 12+ no longer support using fonts installed on the system, so it isn't really a metrics problem but it is that the font is different.
.