You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Safari the cap height of the type for inline code is the x-height of the body type.
The small type obstructs reading flow and makes case harder to distinguish. (In the illustration the majuscule X looks like the minuscule.)
Would comparable font sizes mask the distinction between body text and inline code elements? Two candidate solutions:
A slight but perceptible difference in colour. This might not suffice, because accessibility considerations deprecate relying solely on colour to convey information.
A greater difference between code and body types. If the code type must be APL 385 Unicode to match the IDEs, then we’d want another candidate for the body type.
The text was updated successfully, but these errors were encountered:
Changing the colour is not really an option for the accessibility reason mentioned (although it's how we currently do it in the documentaiton for Dyalog v19.0 and earleir). The fonts need to be consistent with the rest of our documentaiton, so APL385 should be used for code. Howvere, there's no reason it can't be a larger size.
On Safari the cap height of the type for inline code is the x-height of the body type.
The small type obstructs reading flow and makes case harder to distinguish. (In the illustration the majuscule X looks like the minuscule.)
Would comparable font sizes mask the distinction between body text and inline code elements? Two candidate solutions:
The text was updated successfully, but these errors were encountered: