- From: Sylvain Galineau <galineau@adobe.com>
- Date: Tue, 25 Jun 2013 16:24:35 -0700
- To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On 6/25/13 12:59 PM, "fantasai" <fantasai.lists@inkedblade.net> wrote: >On 06/19/2013 12:46 PM, Daniel Glazman wrote: >> FWIW, I have just added UI for the CSS Fonts Module Level 3 >> property 'font-feature-settings' to BlueGriffon. This is >> available if you build yourself BlueGriffon from trunk and >> I will probably have nightly builds with the feature enabled >> tomorrow. Builds will be available from [1]. >> >> I guess it will be an interesting playground for those of you >> interested in font features. John, if you want me to implement >> more features (for instance ss01 to ss20), please let me know. >> >> [1] http://bluegriffon.org/freshmeat/nightlies/latest > >It's interesting to play with, but my concern is that >'font-feature-settings' isn't really designed for uses >that are already covered by CSS3 'font-variant', and >probably shouldn't be used for those. It doesn't have >good cascading behavior, and is really meant for very >specific cases where the author needs to access less >common features. As the spec says, > > # Authors SHOULD generally use ‘font-variant’ and its related > # subproperties whenever possible and only use this property > # for special cases where its use is the only way of accessing > # a particular infrequently used font feature. > >I think within @font-face rules it should be mostly harmless, >but I would be concerned about shipping an editor that allows >it in regular style rules. Since font-feature-settings is what browsers support today - specifically they have limited or not advanced font-variant* support - it makes sense for an editor to produce the content that browsers will render. No different if you're authoring the CSS by hand, really.
Received on Tuesday, 25 June 2013 23:26:11 UTC