macOS Monterey compatibility

Getting Started
1

I want to warn everyone, do not put a new version macOS Monterey, the application does not care with it. In the new version, the hype when you click on the text does not respond to editing, and you cannot add a new text, the program stops responding,

1 Like
2

Thanks for the report Dmitriy!
Another way of saying this: Mac OS Monterey, currently in Beta, introduces new bugs that we will likely need to work around if they are not fixed prior to public release this fall. So make sure you only install the Monterey beta on a testing device, not a mission critical computer you produce Hype content on.

3

This issue has now been resolved in the latest Hype v4.1.7 update.

If you encounter any other macOS 12 Monterey issues (even while it is still in beta), please let us know!

4

I'm running into a problem where Hype won't create a "span" when changing certain fonts. This is only happening in Monterey. For example, if I have a text box that is set for Roboto 300, I can't change a block of text (like a title) to use Roboto 700 Bold, it reverts back to 300. Take the same file, open it in Big Sur, it works fine.

I tried shutting off Suitcase Fusion and re-installed Hype (removing all the Library components), made no difference.

1 Like
5

Thanks for this report. You're right that it does appear to be a Monterey issue (unclear to which 12.x it first occurred right now). We'll be looking into it further.

For now, you'll need to manually add the <span style="font-weight:700"> and </span> tags to the inner html.

6

Hey Jon, any ETA on when this font issue will be fixed? For now just pasting the span tags, which is fine. But when you're working with a lot of text, it's much faster to work in WYSIWYG than in code.

Thanx, Phil.

7

Sorry, there's no timeline on this at the moment.

8

@PMMultimedia, I was finally able to get to the bottom of this issue, and it was quite a doozy!

Short story long:

  • For HTML editing like changing fonts/weights, Hype uses's a WebKit WebView API called applyStyle: that takes arbitrary CSS and then applies it to the selection

  • As far as I can tell, this API never supported setting weights 500 and below... it would simply ignore the CSS directive entirely. Therefore, even Hype 2.0 on Mac OS X 10.8 would not be able to set a font correctly if there were multiple weights in the 100-500 range. However any font weights 600-900 would work just fine.

  • In macOS 12, Apple changed the behavior from using spans with a font-weight value to insert a <b> tag for any of the font weights of 600-900.

  • Hype's "Protect from External Styles" is a CSS Reset that uses an outdated notion of the bold tag. Instead of applying a CSS font-weight of bold (aka equivalent font-weight of 700), it used the CSS bolder attribute. Evidently there was a lot of contention on what browsers should do regarding nested bold tags, so by originally using bolder it would get two <b>'s to continually make text bolder. At some point in Hype's lifetime it was decided this shouldn't be the behavior and 700 should always be used no matter what, but Hype used the older spec for CSS Resets.

  • So when you use a font weight of 300 and then click to use a font weight of 700, Hype on macOS 12 would instead insert a <b> tag, and this would interpret it as bolder which computes to a 400 value. Since you were not including a Roboto 400, and 400 is not close enough to the 700, it would continue showing the 300 weighted font version.

  • Luckily, the span vs <b> tag behavior can be toggled with a little JavaScript via the ancient IE-inspired execCommand() directive with a styleWithCSS value set to true. It took me hours of searching to find this, but I remembered in the back of my head that somewhere there was some setting that might affect this (I don't use execCommand() in Hype and originally thought it was a Mac-based API).

  • There is a partial workaround until a fix is released. In Hype v4.1.8 for working with a single bold font, you can also uncheck the Document Inspector's "Protect from External Styles" since this removes the bolder rule. However if your web page has more than just the .hype document, then it may be vulnerable to stylesheets messing with your design.

Given I consider this a regression I'll be making a v4.1.9 at some point soon to address this. I need to see if there are other high priority bugs to go along with it.

Anyways, thank you much for the continued reporting of this issue!

3 Likes
9

Wow! Thanx so much for looking into this, really appreciate it! I tested the workaround, works perfectly, so I can use that until the update is available. Thanx again!

1 Like
10

Yeah… the one that blocks space in Head HTML for custom fonts even though there is no content in the style block of the font. That would be neat.

Maybe also the one where a focused text field like a data-attribute or custom behavior won't be set if one presses preview while in it. There always needs to be a blur event first. Perhaps you could trigger a blur event before the preview is generated.

If positioning the timelines panel is set to the side, the ratio between view area and timeline panel isn't saved. When you set it up nicely and close and reopen, the ration is arbitrary reset.

Also, switching between apps, back and forth occasionally leads to hidden cursor and missing ability to select anything. Just the macOS sound for blocked is heard. I need to switch away again and come back to unblock.

Some "non-critical", but quality of work fixes.
Small

1 Like