Mathjax and cumulative layout shift - mathjax

Recently google introduced CLS - cumulative layout shift. Mathjax formulas change the CLS. Are there any workarounds?

MathJax v3.2 has an extension that does lazy typesetting (only typesets the expressions as they come into view). As a side effect of that, the position doesn't change due to expressions being typeset above the current view location. You might try upgrading to v3.2 and include the lazy extension in your configuration.

Related

modify katex output html/css?

I've been pretty impressed with Katex's performance. It seems like a good fit as a rendering engine for a WYSIWIG latex editor. However, with MathJax, I can easily inject HTML/CSS in arbitrary locations using the \class directive. I can then use these injected classes for blinking cursors, gray boxes, and what not. For example:
Is there a way to do the same thing with Katex? In particular, I need the ability to inject HTML/CSS in arbitrary locations in the equation.
This is not currently supported. There is an open issue on the Github page.

Font-face and vertical position of text

I want to use After Disaster font on my website, but I can't achieve the same vertical position of displayed text in different browsers. Even more - it is dependent on system too. You may test this:
http://jsfiddle.net/z7rby/1/
On Linux Google Chrome displays text about one pixel higher than Firefox and Opera. On Windows Google Chrome displays it in the middle of background. What can I do with that?
There is no way to solve this problem. You have to accept that fonts will be rendered slightly differently on different systems, and find another way to achieve your visual goals.
You can control your layout via positioning CSS e.g. width, height but not font rendering.
If that level of control is not "good enough" then you can write browser-dependent CSS (tutorials exist online) to compensate for differences.
But please remember the goal in all computing is "good enough": Perfection is not cost-effective!
Once you have achieved a level where further improvements require a certain effort, but there are more important things to spend that effort on, that is the point when you have finished.

How to show "..." when there's not enough space to view all the text

How does jQueryMobile shows "..." when there's not enough space to view all the text?
Is it an CSS attribute?
There is a CSS attribute for this -- it is text-overflow:ellipsis;.
However, there is one problem with it: it doesn't work in Firefox. It works in all other browsers, but not Firefox, not even FF4. I understand it's planned for FF5 or FF6.
In Firefox, it would need to be done using pure Javascript, which is where the JQuery would need to do some work. To do it accurately, it would need to calculate the physical size of the text in pixels, character by character. It is possible that it does use the CSS property in other browsers. It would make sense.
See this post: text-overflow:ellipsis in Firefox 4? (and FF5) for a further discussion of this issue specific to Firefox.

Better dialog shadows in YUI 2?

Here's a tricky one: has anybody seen a YUI dialog/panel implementation with nice OS X style shadows around the dialog, instead of the blocky shadow that is implemented by default with the "underlay" element?
You can see this type of shadow on Amazon.com popup windows. It requires quite a bit of PNGs but looks very nice.
I'm thinking of inserting extra DIVs or replacing the .underlay element, and hook into the dialog size event to adapt the dimensions. The latter would be required because YUI uses some CSS trickery to make the underlay element "snap" to the dialog dimensions with CSS only in modern browsers, and uses a manual dimension update for IE.
EDIT: Just checked YUI 3. The Panel widget is not available yet, only the Container and it's still beta. So I'm looking at solving this in YUI 2.
PS: Oh I guess I could include the PNG shadow as part of the Panel's header, body and footer (hd, bd, ft), as an extra padding. And use a css rule to hide YUI's underlay. Hmmmmmm I just wish I didn't have to do this because it changes calculations for the draggable area, it's not a great way to do it.

Working arround font rendering issues in all major browsers

Since long time i been having a real problem with the different ways that each browser display text.
Sure you have noticed that even when you create a stylesheet specifying everything about the font properties, still every browser display the same text with some differences, the usual problem is the font weight, that even if you specify it different browsers display it different ways.
I would like to know if some as come with a solution. Not turning the text into a image.
Thanks.
EDIT:
This is a example of the problem. On the left Firefox and right IE. However i have defined in the CSS font family, weight, size and still they render the fonts different.
Snapshot
Do you mean that on one browser its bold and another one its normal? A reset should fix that, but if it doesn't, it might be something overriding that.
If you're talking about fonts looking different, it is possible - for example, since Google Chrome / Chromium sandboxes the renderer process, the font rendering won't be affected by other parts of the system, and I believe that it uses some sort of special font rendering. To be honest, on my Linux install, I do get bolder fonts on Chromium, but Firefox displays them fine.
There's SIFR (as pointed above), but it needs Flash and it is a bit heavy. There's also Cufon http://cufon.shoqolate.com/ that uses Javascript. Could you show a screencast so we know what's the problem? Thanks.
SIFR is a good solution, as long as you're only trying to control the appearance of small chunks of text (headings, design elements, etc.)
Beyond that, browsers are perfectly allowed to render text any way they want, and getting it pixel-perfect between browsers and operating systems is usually not even desirable for larger chunks of text. Users will have different accessibility settings and anti-aliasing settings which are tuned to the way they want to read text, and in general websites should try to respect that.
You can use SIFR.
Although this problem is already about a week old, here is a solution that I found, that might be related:
http://blog.wolffmyren.com/2009/05/28/jquery-fadeinfadeout-ie-cleartype-glitch/
If you're not using jQuery, try removing the filter attribute from the elements that are displaying non-Cleartype'd text and it should work, according to that blog post.

Resources