- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Aug 2015 23:42:20 +0200
- To: Stephen Zilles <szilles@adobe.com>, "www-style@w3.org list (www-style@w3.org)" <www-style@w3.org>
On 08/27/2015 12:32 PM, Stephen Zilles wrote: > > The above problem can be mitigated a bit by careful use of the replaced elements. If all the elements are 1EM high and they > are positioned with other elements that are 1EM high, it is far less likely that the calculation of the line box height will > be too short even when the replaced elements are positioned by adjusting the bottom margin. > > It has also been suggested that using the bottom margin change would adjust all the baselines, correctly. Even for the two > baselines currently specified, it is unlikely that this will work for lower case letters with descenders. > > The best solution to the problem of defining baselines for objects which do not naturally have them would be to define a > property that allows a baseline table to be defined. Totally agree that the ultimate way forward is a baseline-table property such as you describe. However, I think that for the common case of wanting a set of images to be used as glyphs, it is adequate to design these images on the em square, just as if they were real glyphs in a font, and use the margin properties. I.e. to solve the case of gaiji with an alphabetic baseline at 12%, implement each letter in a 1em-tall image, so that aligning them all in a row creates a 1em tall line of perfectly aligned text. Then size each image to 1em (height: 1em), and set its bottom margin to -0.12em. This technique will solve the vast majority of all cases for image letters. As you note, it won't solve drop-caps, but neither will alignment-point. So I think at some point we'll want a baseline-table property, but not in this level. :) ~fantasai
Received on Thursday, 27 August 2015 21:42:49 UTC