- From: Sergey Malkin <sergeym@microsoft.com>
- Date: Tue, 9 Mar 2010 19:18:50 +0000
- To: www-style list <www-style@w3.org>
Thomas Phinney wrote: >> I suppose one could turn on 'hist' and 'hlig' with a single toggle, which might also do 'onum' and 'pnum', but one needs to access the numeric stuff separately anyway. Christoph Päper wrote: > We do have other instances where there are several (shorthand) properties that interact, e.g. the width of the top border can be set by 'border-top-width', 'border-top', 'border-width' and 'border'. Proposed properties only look like, but are _not_ shorthand. They would be if there are individual properties for each independent part, but this is not the case. Instead of three individual properties for different types of ligatures and enabled/disabled value for each, draft introduces special keywords to turn each individual ligature type on or off and special inheritance rules. I see several problems with this approach versus individual properties: - UA implementation should track and inherit each feature independently, because value is not shorthand and can't be broken into individual properties. Normal inheritance does not work, and to understand if OpenType 'liga' feature should be applied to particular piece of text, three ligature types should be treated internally like individual properties. - It would cause problems with cascading. Since only one of property declarations will be applied, following style sheet will not enable standard ligatures on title div: div { font-variant-ligatures: common-ligatures; } .title { font-variant-ligatures: additional-ligatures; } - Tooling and object model clients will be better tracking these features independently too. Consider document editor inside HTML page with toolbar allowing to use different typographic features. Script on such page should be able to understand if standard ligatures or Stylistic Set 1 are applied at current cursor position and highlight corresponding button. How computed style should work for these properties? Will every script need to parse these non-trivial definitions? Thanks, Sergey
Received on Tuesday, 9 March 2010 19:19:29 UTC