Avoid line breaks for inline math in in WebKit. #1982 #2006
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…r inline math. This will fail to get the cwidth for inline math inside shrinkwrapping elements (like <td> or ones with display:inline-block), but inline elements shouldn't use cwidth anyway unless there are explicit line breaks.
…width (2 less than full size), and if cwidth is 0, use default width
…lock elements when computing cwidth for inline math.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the method of determining the em and ex sizes, and the container width so that display is not set to any block-level values for inline mathematics. This is fine for the em and ex sizes, but the new mechanism has a downside for finding the container width: if the inline math is inside a shrink-wrapped element (like a
<td>, or an element withdisplay:inline-block) with no display math, then the container width will be the size of the container without the mathematics, rather than the maximum width available to the shrink-wrapped element, as it is now. Fortunately, in-line math does not use the container width except in unusual situations (e.g., when there is an explicit line break in the math), so it should not affect most uses. For those situations where this is a problem, adding an empty display math should resolve the issue (you could put it in a div with height 0px to avoid the extra space it would introduce).Resolves issue #1982.